[x3d-public] [x3dom-users] Whither protoexpander in X3DOM? umm, just define input-to-output and write code

[Andreas Plesch]

I could not resist a proof of concept for the subgraph inclusion part of Protos.

https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html

This is an absolutely minimal start. There is only creation of
instances, using only the first element in the ProtoBody. There is no
ProtoInterface or events handling.
It should work for all single node Protos.

But it only took a few lines in the right place
(https://github.com/andreasplesch/x3dom/commit/1e0ff82c2f7c77adcb521d62ff5172cf159943fb).

I understand that only the first node in a ProtoBody is used for the
template. It can be of course a grouping node. Other nodes in the
ProtoBody can affect the first node with internal routing.

Inline is in effect a grouping node but this will not translate to
ProtoInstance. I will have to look at more examples to understand
better how multiple nodes are inserted with a single ProtoInstance.

-Andreas



On Thu, May 28, 2020 at 3:09 PM Andreas Plesch <andreasplesch at gmail.com> wrote:
>
> Let me write down a few notes on ProtoDeclare/Instance.
>
> - The expander approach would be ok for x3dom as well but I am not
> sure if it is easier to implement.
> - These are Statements and would be handled separately from Nodes,
> similar to ROUTE, in x3dom in NodeNameSpace.js
> - in x3dom gltf inlines are handled by translation to a (by default
> non-accessible) sub DOM, which is then tree parsed and added as a
> subgraph in a child namespace to the main scene. Similar to
> ProtoInstance this involves some processing before attaching to the
> main scene. So I think it would be not too hard to do the same for
> ProtoInstance by looking up the corresponding ProtoBody in a registry.
> The registry is populated while parsing, looking for ProtoDeclare
> elements.
> - the main challenge is how to implement custom fields, and 'IS' ing.
> For routing to ProtoInstances there needs to be a crossing of the
> namescope boundary.
> - ProtoInstances are more like Nodes than Statements, since they need
> to be included in traversing the scene.
> - not sure if x3dom currently has a way to send events into namescoped
> subgraphs (via IS/connect), and capture events from those (via
> IS/connect).
> - perhaps it makes sense to have the ProtoInstance statement construct
> a ProtoInstanceNode node to insert in the scenegraph. The statement
> takes care of field definitions for the node, and the node takes care
> of ISing and events during travesal.
>
> -Andreas
>
>
>
>
>
> On Thu, May 28, 2020 at 12:52 AM John Carlson <yottzumm at gmail.com> wrote:
> >
> > so perhaps this is the reasoning Leonard had.:
> >
> > Developers and designers want the full power of the web.   If I restrict people to inlines, they can’t use standard tools to inspect the DOM, especially where it’s critical.
> >
> > 1.   Should X3D4 allow all X3D elements in the HTML page or perhaps just a few?
> >
> > 2.  Should X3D4 allow Protos on the main HTML page?  Or only in inlines?
> >
> > John
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453



-- 
Andreas Plesch
Waltham, MA 02453