[x3d-public] HTML Imports and ShadowDOM experiments

[Andreas Plesch]

Ok, I could adapt the Rotor prototype example as a x3dom web component here:

https://glitch.com/edit/#!/x3dom-webprotos-2?path=index.html:26:4

https://x3dom-webprotos-2.glitch.me

Since the rotor prototype internally uses DEF node names for routing, I had
to add name scoping per proto instance. Ideally, if x3d would work in a
shadowdom, the shadowdom would provide the encapsulation of name scopes but
since x3dom does not 'see' a shadowdom I needed to add unique suffixes to
all occurrences of node names in a proto (template) instance.

But this was the only necessary addition to template processing.

The example also exercises DEF/USE of nodes used as field values and
nesting of proto instances which both seem to work.

To take further advantage of web components, it may be possible to use a
x3dproto base class for shared methods  which extended custom proto
elements would use.

There are severe limitations such as no MFNode type fields or only indirect
routing. x3d scripting needs to be substituted by component methods.

But overall using web components could be a HTML integrated, standards
based approach to prototyping and instancing.

Andreas

On Mon, Aug 28, 2017 at 1:38 AM, Andreas Plesch <andreasplesch at gmail.com>
wrote:

> Trying to realize a x3d prototype style instancing for x3dom, I added use
> of html5 custom elements in addition to html5 templates and shadowdom here:
>
> https://x3dom-webprotos.glitch.me/
> https://glitch.com/edit/#!/x3dom-webprotos?path=index.html:24:7
>
> The main work happens in processTemplate() which takes the template,
> populates it with instance values and brings the instance out of the
> shadowdom into the lightdom so x3dom can 'see' it.
>
> https://glitch.com/edit/#!/x3dom-webprotos?path=table_proto.html:81:2
>
> processTemplate() is fairly generic and may work for other templates
> (proto declarations) such as the rotor proto:
>
> http://www.web3d.org/x3d/content/examples/Basic/X3dSpecifica
> tions/RotorIndex.html
>
> I may try this next.
>
> -Andreas
>
> On Wed, Jul 26, 2017 at 12:27 PM, Andreas Plesch <andreasplesch at gmail.com>
> wrote:
>
>> On Sun, Jul 23, 2017 at 12:32 PM, Andreas Plesch <andreasplesch at gmail.com
>> > wrote:
>>
>>>
>>>
>>> On Sat, Jul 22, 2017 at 4:01 PM, Andreas Plesch <andreasplesch at gmail.com
>>> > wrote:
>>>
>>>>
>>>>
>>>> On Fri, Jul 21, 2017 at 10:24 AM, Andreas Plesch <
>>>> andreasplesch at gmail.com> wrote:
>>>>
>>>>>
>>>>> ...
>>>>> It could also be fruitful to investigate how custom elements with
>>>>> templates compare with protos in detail. There seems to be match in purpose
>>>>> and ability.
>>>>>
>>>>
>>>> ...
>>>> It may be possible to process the attached and populated template to
>>>> replace slot elements with their corresponding assigned nodes. This leaves
>>>> the first problem or parenting (a universal one !). One solution may be to
>>>> move the shadow root nodes out and into the light dom under the shadow
>>>> host. ..
>>>>
>>>
>>> After writing this, I went ahead and tested this idea. It turns out that
>>> it actually works (only for chrome):
>>>
>>> https://glitch.com/edit/#!/tiny-fact?path=index.html:70:5 and Show Live.
>>>
>>> I added a slotted template using this web3d example:
>>> http://www.web3d.org/x3d/content/examples/Basic/X3dSpecifica
>>> tions/PrototypeIndex.html
>>>
>>> The template has slots for a color field(attribute) and a material
>>> field(element):
>>> https://glitch.com/edit/#!/tiny-fact?path=table_template.html:12:7
>>> https://glitch.com/edit/#!/tiny-fact?path=table_template.html:27:15
>>>
>>> Cloning the template then into the root of shadow dom (attached to a
>>> group node) causes assignment of values to the named slots now in the
>>> shadow dom. One can then process these values to become actual x3dom field
>>> values. This does not require a lot of processing:
>>>
>>> https://glitch.com/edit/#!/tiny-fact?path=index.html:70:14
>>>
>>> But it took a while to pin down the details.
>>>
>>> It is interesting that it was natural to keep Prototype's nodeField and
>>> fieldValue semantics.
>>>
>>> For the instance: https://glitch.com/edit/#!/tin
>>> y-fact?path=index.html:30:1
>>>
>>> <x3d-Group id="tablehost">
>>>       <fieldValue slot="tableTopMaterialColor" value="1 1
>>> 1"></fieldValue>
>>>  </x3d-Group>
>>>
>>> and for the template (prototype): https://glitch.com/edit/#!/tin
>>> y-fact?path=table_template.html:12:0
>>>
>>> <Material DEF='TableTopMaterial' diffuseColor='.6 .6 .1'>
>>>   <slot name='tableTopMaterialColor' nodeField='diffuseColor'>
>>>      <fieldValue value='.6 .6 .1'></fieldValue> <!-- default -->
>>>    </slot>
>>>
>>> Since x3dom does not know how to deal with shadow dom, it is necessary
>>> to move the processed shadow dom into the light dom. But this requires only
>>> one line:
>>>
>>> https://glitch.com/edit/#!/tiny-fact?path=index.html:81:1
>>>
>>> The example is just for testing the process and does not make an attempt
>>> to generalize or wrap the process to be applied easily to any template. I
>>> do think wrapping this into a general ProtoInstance like web
>>> component/custom element is quite doable.
>>>
>>> So perhaps I was too pessimistic and in fact it may be possible to rely
>>> on web components for prototype like functionality.
>>>
>>> First, I want to check if modifying the slot value in a template
>>> instance gets picked up by x3dom. Probably not for attribute fields. hm.
>>>
>>>
>> Obliterating the line number references above, I updated
>>
>> https://glitch.com/edit/#!/tiny-fact?path=index.html:94:1 and show Live
>>
>> to enable updates to the fieldValues in template instances. It was only
>> necessary to observe the mutations of the values and then update the field
>> in the actual node accordingly.
>>
>> The change color button sets the value attribute of the fieldValue
>> element which is linked to the template by a named slot. The nodeField
>> attribute (here 'diffuseColor') of the slot links the slot to a field of
>> the parent of the slot. Using these relations it does not take much to
>> transmit a changed fieldValue value of the instance to the actual node in
>> the template clone.
>>
>> To enable updates to SFNode type fields of a template instance, no
>> additional code was necessary since the instance's node (linked by a slot)
>> is directly used in the template clone by moving it into the template
>> clone. This is what the change material button tests. It changes both the
>> color and the shininess of the material node in the instance.
>> What was interesting is that it is possible to use a USE material node in
>> the instance and put the corresponding DEF material outside somewhere else.
>> Since the DEF node does not get moved, it can be more easily selected.
>> However, direct selection by id or other attributes of the moved node
>> should also be very straightforward. It should also be possible x3d route
>> to it directly.
>>
>> Routing to nodeField defined 'fields' of a cloned, slotted template is
>> currently not possible. Hm, it may perhaps be possible to define an actual
>> fieldValue x3dom node with a 'value' field (of flexible type) which can
>> receive routed values and does nothing but update the value attribute of
>> its dom node.
>>
>> The next step would be to see how to include scripts in templates. Script
>>> tags can be part of templates. They get executed when the template is
>>> instanced by cloning. Another place for scripting is in a custom element.
>>> Templates are often used with custom elements. A custom element would be
>>> the way to wrap the js in the example.
>>>
>>> -Andreas
>>>
>>> --
>>> Andreas Plesch
>>> 39 Barbara Rd.
>>> Waltham, MA 02453
>>>
>>
>>
>>
>> --
>> Andreas Plesch
>> 39 Barbara Rd.
>> Waltham, MA 02453
>>
>
>
>
> --
> Andreas Plesch
> 39 Barbara Rd.
> Waltham, MA 02453
>



-- 
Andreas Plesch
39 Barbara Rd.
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170828/ec5dcdb7/attachment-0001.html>