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

[John Carlson]

Here are the JSON PROTO code I am aware of:

X_ITE loads JSON containing PROTOs and X3D scripting!

X3DOM contains the JSON PROTO code I developed as part of the X3DJSONLD
project, last I checked.

So we have several ways to do JSON PROTOs. What I am trying to figure out
is whether the Andreas’ XML PROTO code in X3DOM also handles JSON.  Then I
can safely remove my JSON PROTO code and rely on X_ITE and X3DOM.

I realize this is a case of UTSL.   My time online lately has been
struggling, trying to get a good backup so I can reinstall an OS.

John


On Fri, Jun 26, 2020 at 1:02 PM Andreas Plesch <andreasplesch at gmail.com>
wrote:

> I think it is valuable as long as there is no other way to use json
> prototypes. -Andreas
>
> On Fri, Jun 26, 2020 at 10:10 AM John Carlson <yottzumm at gmail.com> wrote:
> >
> > I guess I should ask whether proto expansion is valuable enough to
> remain a checkbox in X3DJSONLD.   Anyone?
> >
> > On Thu, Jun 25, 2020 at 9:39 PM Andreas Plesch <andreasplesch at gmail.com>
> wrote:
> >>
> >> I think that could be helpful. I do plan on merging the proto support
> >> into the dev x3dom version. But it needs to be pretty robust. For
> >> example, people will experiment with dom manipulation of protoinstance
> >> field values or even protobody nodes, and expect something to happen,
> >> like changing all instances by changing the proto definition, after
> >> the fact. Also adding a new protodeclaration to an existing scene
> >> needs testing but should work. Removing one is less critical.
> >>
> >> Thanks, -Andreas
> >>
> >> On Thu, Jun 25, 2020 at 9:08 PM John Carlson <yottzumm at gmail.com>
> wrote:
> >> >
> >> > Andreas, I’m just checking to see if you’ve removed the JSON proto
> expander from the code.  Would you like me to pursue removing the expander
> and test your code after it gets through the JSONParser?
> >> >
> >> > Thanks!
> >> >
> >> > John
> >> >
> >> > On Tue, Jun 16, 2020 at 8:20 AM Andreas Plesch <
> andreasplesch at gmail.com> wrote:
> >> >>
> >> >> I am switching to a new implementation of Protos in x3dom. Most
> basic proto examples in
> >> >>
> >> >>
> https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html
> >> >>
> >> >> started to work with the new implementation but routing in and out
> of a protoinstance is still missing.
> >> >>
> >> >> The new implementation defines a new node type for each ProtoDeclare
> which then can be used like a native node. As a consequence, it will be
> possible to optionally use a different syntax for ProtoInstance nodes. One
> can just the the regular syntax for nodes:
> >> >>
> >> >> < nodename fieldname="fieldvalue" >
> >> >>   < childnode />
> >> >> </ nodename >
> >> >>
> >> >> This is more similar to the vrml encoding of protoinstances.
> >> >>
> >> >> -Andreas
> >> >>
> >> >>
> >> >> On Mon, Jun 8, 2020 at 5:34 PM Andreas Plesch <
> andreasplesch at gmail.com> wrote:
> >> >>>
> >> >>> I could identify the scoping and other issues to get working spin
> group and proto_nested examples:
> >> >>>
> >> >>>
> https://5edeabda853f6d72e3a951a8--x3dom.netlify.app/examples/functional/proto/inline.html
> >> >>>
> https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html
> >> >>>
> >> >>> The scoping issue with spin group was that a DEF in a ProtoInstance
> node fieldValue belongs to the namescope of the parent of the
> ProtoInstance, not just to the namescope of the ProtoInstance itself. Only
> the DEF names used in the ProtoBody are restricted to the namescope of the
> corresponding ProtoInstance.
> >> >>>
> >> >>> For the proto_nested example, there was a need to identify the case
> when a ProtoInstance has ISing, eg. is used inside a ProtoBody of another
> Proto which connectd to the fields of the ProtoInstance. As far as I
> remember Castle Engine does something similar. It is not beautiful, and I
> am not sure the bolted on solution works with deeper ISing.
> >> >>>
> >> >>> I may try a few more of the castle demo models. Perhaps there are
> more fairly easy to fix problems.
> >> >>>
> >> >>> Any feedback still very welcome,
> >> >>>
> >> >>> -Andreas
> >> >>>
> >> >>>
> >> >>>
> >> >>> On Mon, Jun 8, 2020 at 12:56 PM Andreas Plesch <
> andreasplesch at gmail.com> wrote:
> >> >>>>
> >> >>>> Looking at harder, more nested examples revealed quite a few
> problems which are only partially fixed here:
> >> >>>>
> >> >>>>
> https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html
> >> >>>>
> https://5ede6856ca50c48058af6ed6--x3dom.netlify.app/examples/functional/proto/inline.html
> >> >>>>
> >> >>>> This includes the spin group example and a few castle demo models.
> Fixes include more careful parsing, route normalization and proto
> declaration transfer into child name scopes.
> >> >>>>
> >> >>>> Spin group almost works but has trouble with DEF/USE name scoping
> of the TouchSensor (a different scoping problem than the table2/leg2
> problem in proto_nested). Incidentally, the TouchSensor does not seem to
> react in freeWrl also.
> >> >>>>
> >> >>>> I may try to describe the DEF/USE name scoping issue in spin group
> in another request for clarification.
> >> >>>>
> >> >>>> I think it may be time to scrap this attempt and start over with a
> different approach since the code is now too complex. A new approach would
> probably define a new ProtoInstanceNode which fits better into the existing
> x3dom infrastructure.
> >> >>>>
> >> >>>> -Andreas
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> On Fri, Jun 5, 2020 at 3:24 PM Andreas Plesch <
> andreasplesch at gmail.com> wrote:
> >> >>>>>
> >> >>>>> I added an example of a Prototype generating an output event, an
> >> >>>>> IntegerTrigger which only triggers upon receiving true:
> >> >>>>>
> >> >>>>>
> https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html
> >> >>>>>
> https://5eda866f96703e0007fba0af--x3dom.netlify.app/examples/functional/proto/inline.html
> >> >>>>>
> >> >>>>> The implementation adds forwarding of internal node generated
> events
> >> >>>>> to the ProtoInstance pseudo node, using the internal x3dom route
> >> >>>>> mechanism.
> >> >>>>>
> >> >>>>>  I think that concludes this effort for Prototype support in
> x3dom.
> >> >>>>> Most functionality should be available.
> >> >>>>>
> >> >>>>> Missing features are
> >> >>>>>
> >> >>>>> - DOM based modification of ProtoInstance field values (probably
> possible)
> >> >>>>> - routing of node value fields (in x3dom in general), but it is
> >> >>>>> possible to use ProtoInstance fieldValue for node values.
> >> >>>>> - no Script node support (in x3dom in general), unrelated although
> >> >>>>> Scripts are very often used in Prototypes.
> >> >>>>>
> >> >>>>> There are no plans from my side to add support for these missing
> features.
> >> >>>>>
> >> >>>>> Builds for testing more thoroughly are available here:
> >> >>>>>
> >> >>>>> https://5eda866f96703e0007fba0af--x3dom.netlify.app/
> >> >>>>>
> >> >>>>> In particular, nested situations need testing, eg. ProtoInstances
> in
> >> >>>>> ProtoDeclaration, ProtoInstances in ProtoInstance fields, and
> >> >>>>> ProtoDeclarations in ProtoInstances (if that makes sense).
> >> >>>>>
> >> >>>>> I should check the castle library of examples.
> >> >>>>>
> >> >>>>> After a period of testing, ExternProto support should be
> relatively
> >> >>>>> less complicated to provide.
> >> >>>>>
> >> >>>>> Looking forward to any reports,
> >> >>>>>
> >> >>>>> -Andreas
> >> >>>>>
> >> >>>>> On Thu, Jun 4, 2020 at 1:56 PM Andreas Plesch <
> andreasplesch at gmail.com> wrote:
> >> >>>>> >
> >> >>>>> > Just another incremental update which enables event routing into
> >> >>>>> > ProtoInstances, via forwarding to the internal nodes:
> >> >>>>> >
> >> >>>>> >
> https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html
> >> >>>>> >
> https://5ed930d641a27700082647b9--x3dom.netlify.app/examples/functional/proto/inline.html
> >> >>>>> >
> >> >>>>> > Sofar it was possible to treat ProtoInstance as a statement
> without
> >> >>>>> > generating a full X3DNode derived member of the scene graph.
> This was
> >> >>>>> > easier to reason about, following the expansion approach. But I
> start
> >> >>>>> > to think it required essentially reimplementing enough of the
> X3DNode
> >> >>>>> > related functionality that it may be time to try to switch to
> have a
> >> >>>>> > ProtoInstanceNode itself in the scenegraph which then internally
> >> >>>>> > represents itself with the Proto definition.
> >> >>>>> >
> >> >>>>> > What would be a good example to test routing events emitted
> from a
> >> >>>>> > ProtoInstance, without a script node ? Eg. a useful Proto which
> >> >>>>> > generates events ? Perhaps a combination of event utilities ?
> >> >>>>> >
> >> >>>>> > -Andreas
> >> >>>>> >
> >> >>>>> > On Wed, Jun 3, 2020 at 7:17 PM Andreas Plesch <
> andreasplesch at gmail.com> wrote:
> >> >>>>> > >
> >> >>>>> > > I could enable custom fields for Protos, eg. ProtoInterface,
> >> >>>>> > > IS/connect and ProtoInstance fieldValue, to a usable degree:
> >> >>>>> > >
> >> >>>>> > >
> https://5ed82885ae201410e81024b3--x3dom.netlify.app/examples/functional/proto/inline.html
> >> >>>>> > >
> https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html
> >> >>>>> > >
> >> >>>>> > > ( key 'a' or 'r' of you do not see the fish, to adjust the
> view. )
> >> >>>>> > >
> >> >>>>> > > SFNode type fields work, MFNode type fields perhaps also.
> Initial
> >> >>>>> > > value from ProtoInterface, and using the ProtoInstance field
> value
> >> >>>>> > > otherwise should work. Routing from and to a ProtoInstance
> does not
> >> >>>>> > > work yet. Is there an example _without_ Script node which
> uses routes
> >> >>>>> > > from or to a ProtoInstance ?
> >> >>>>> > >
> >> >>>>> > > I also came across the question what to do if in a ProtoBody
> a node
> >> >>>>> > > which has a IS field connection to a ProtoField with an
> initial value,
> >> >>>>> > > also has a field value for the same field. Here is an example:
> >> >>>>> > >
> >> >>>>> > > <ProtoInterface>
> >> >>>>> > >   <field accessType='inputOutput' name='color' type='SFColor'
> value='0,0,0'/>
> >> >>>>> > > ...
> >> >>>>> > >
> >> >>>>> > > <ProtoBody>
> >> >>>>> > >   <Material diffuseColor='1,0,0'>
> >> >>>>> > >      <IS>
> >> >>>>> > >         <connect protoField='color' nodeField='diffuseColor'
> />
> >> >>>>> > > ...
> >> >>>>> > >
> >> >>>>> > > Is the initial color 0,0,0 (black) or 1,0,0 (red) ? Probably
> black.
> >> >>>>> > >
> >> >>>>> > > To avoid this redundancy, the initial value could only be
> defined in
> >> >>>>> > > the ProtoBody, in a future iteration of X3D.
> >> >>>>> > >
> >> >>>>> > > All the code is still NodeNameSpace.js. It was possible to
> keep it
> >> >>>>> > > separate from existing functions. The approach for field
> manipulation
> >> >>>>> > > is largely via DOM updates of cloned ProtoBodies. This avoids
> having
> >> >>>>> > > to deal with field value types.
> >> >>>>> > >
> >> >>>>> > > I have an idea for Routing, so this is next. A good example
> would be
> >> >>>>> > > great. Perhaps animating the table colors is an easy one
> first.
> >> >>>>> > >
> >> >>>>> > > -Andreas
> >> >>>>> > >
> >> >>>>> > > On Mon, Jun 1, 2020 at 8:09 AM Andreas Plesch <
> andreasplesch at gmail.com> wrote:
> >> >>>>> > > >
> >> >>>>> > > > Ok, true.
> >> >>>>> > > >
> >> >>>>> > > > If default values are the main reason to have a
> ProtoInterface, they could be just moved into the connect tag as a value
> attribute.
> >> >>>>> > > >
> >> >>>>> > > > Alternatively, the spec. could define that default values
> always fall back to the default value of the connected field of a native
> x3d node. The recommendation is any case to provide values for all fields
> in a ProtoInstance since a Proto may not be well documented.
> >> >>>>> > > >
> >> >>>>> > > > So simplifying protos may be possible by only relying on IS
> connections to define fields and omitting or moving the ability to allow
> custom default values.
> >> >>>>> > > >
> >> >>>>> > > > ProtoInterface does provide a nice, consolidated place to
> list all parameters for a Proto. But that is really a documentation
> feature, and ProtoDeclares typically are accompanied by an example
> ProtoInstance intended to show how to use Proto parameters/fields.
> >> >>>>> > > >
> >> >>>>> > > > Lastly, ProtoInterface does allow restricting access to
> native inputoutput fields to only input or only output. But when is that
> ability really useful ? Authors know how a Proto is intended to be used,
> and implementations have to support all access types in any case.
> >> >>>>> > > >
> >> >>>>> > > > Protos are very verbose in the xml encoding. So not needing
> a ProtoInterface section would help a little with cutting down this
> verbosity.
> >> >>>>> > > >
> >> >>>>> > > > Andreas
> >> >>>>> > > >
> >> >>>>> > > > ---on the phone---
> >> >>>>> > > >
> >> >>>>> > > > On Sun, May 31, 2020, 7:11 PM John Carlson <
> yottzumm at gmail.com> wrote:
> >> >>>>> > > >>
> >> >>>>> > > >> We need protointerface for default values.
> >> >>>>> > > >>
> >> >>>>> > > >> On Sun, May 31, 2020 at 4:50 PM Andreas Plesch <
> andreasplesch at gmail.com> wrote:
> >> >>>>> > > >>>
> >> >>>>> > > >>> I adopted the idea to put the helper/sibling nodes of a
> ProtoInstance
> >> >>>>> > > >>> into a Switch node, which is added as a root node to the
> main scene.
> >> >>>>> > > >>> See the new MaterialBlinker proto here:
> >> >>>>> > > >>>
> >> >>>>> > > >>>
> https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html
> >> >>>>> > > >>>
> https://5ed41e4b7244550007f7272f--x3dom.netlify.app/examples/functional/proto/inline.html
> >> >>>>> > > >>>
> >> >>>>> > > >>>
> https://github.com/andreasplesch/x3dom/blob/gh-pages/test/functional/proto/MaterialBlinker.x3d
> >> >>>>> > > >>>
> >> >>>>> > > >>> The added switch node exists only in the x3d graph, not
> in the dom
> >> >>>>> > > >>> graph, so is kind of hidden.
> >> >>>>> > > >>>
> >> >>>>> > > >>> This is starting to have wider use compared to DEF/USE
> instancing.
> >> >>>>> > > >>>
> >> >>>>> > > >>> The next step would be routable fields. It would be nice
> to break down
> >> >>>>> > > >>> that functionality into smaller units.
> >> >>>>> > > >>>
> >> >>>>> > > >>> One way to think about IS/connect is to ignore the
> ProtoInterface
> >> >>>>> > > >>> definition initially and use directly the field names
> mentioned in the
> >> >>>>> > > >>> connect tag to establish additional internal routes. It
> may be
> >> >>>>> > > >>> preferable to modify routes since sofar there is no actual
> >> >>>>> > > >>> ProtoInstanceNode node with actual fields. An idea may be
> to define
> >> >>>>> > > >>> such a node which does not do anything other than define
> the custom
> >> >>>>> > > >>> fields and forward events to the internal nodes.
> >> >>>>> > > >>>
> >> >>>>> > > >>> Would it be possible to autogenerate a ProtoInterface
> definition from
> >> >>>>> > > >>> a ProtoBody with IS connections ? The fields names are
> all there and
> >> >>>>> > > >>> the access types just follow the types from the native
> nodes. Do we
> >> >>>>> > > >>> actually need a ProtoInterface definition ?
> >> >>>>> > > >>>
> >> >>>>> > > >>> -Andreas
> >> >>>>> > > >>>
> >> >>>>> > > >>> On Sat, May 30, 2020 at 12:30 PM Andreas Plesch <
> andreasplesch at gmail.com> wrote:
> >> >>>>> > > >>> >
> >> >>>>> > > >>> > Sorry, I misunderstood how Switch could help. I missed
> the expanded example:
> >> >>>>> > > >>> >
> >> >>>>> > > >>> >
> http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14Prototypes/MaterialModulatorPrototypeExpandedIndex.html
> >> >>>>> > > >>> >
> >> >>>>> > > >>> > The Switch node containing the sibling/helper nodes is
> just appended
> >> >>>>> > > >>> > to the end of the main scene, not after the main node.
> Does that work
> >> >>>>> > > >>> > in general ? It may (but nesting?). It also means that
> the siblings
> >> >>>>> > > >>> > nodes can only be X3DChildNodes which also may be ok.
> Could there be
> >> >>>>> > > >>> > non child nodes which are used as helpers nodes ? I
> cannot think of
> >> >>>>> > > >>> > any right now although the spec. does not seem to
> restrict what is
> >> >>>>> > > >>> > inside a Proto definition.
> >> >>>>> > > >>> >
> >> >>>>> > > >>> > Let's think about nesting and DEF/USE. USE of
> ProtoInstance may work
> >> >>>>> > > >>> > by just placing a USE instance of the main node, upon
> expansion or
> >> >>>>> > > >>> > scene construction. I think it could.
> >> >>>>> > > >>> >
> >> >>>>> > > >>> > But where would the sibling Switch go for a nested
> ProtoInstance,
> >> >>>>> > > >>> > inside a ProtoBody ?
> >> >>>>> > > >>> >
> >> >>>>> > > >>> > I will try to add some diagrams but this will be quite
> dizzying.
> >> >>>>> > > >>> > Apologies for that.
> >> >>>>> > > >>> >
> >> >>>>> > > >>> > If the ProtoInstance is or is inside the first, main
> node, upon
> >> >>>>> > > >>> > expansion a potential sibling Switch would be appended
> after the
> >> >>>>> > > >>> > siblings of the first node, as another sibling:
> >> >>>>> > > >>> >
> >> >>>>> > > >>> > ProtoBody
> >> >>>>> > > >>> >   main node: ProtoInstance
> >> >>>>> > > >>> >   siblings
> >> >>>>> > > >>> >
> >> >>>>> > > >>> > expansion ->
> >> >>>>> > > >>> >
> >> >>>>> > > >>> > ProtoBody
> >> >>>>> > > >>> >   main node: ProtoInstanceExpandedMain
> >> >>>>> > > >>> >   siblings
> >> >>>>> > > >>> >   ProtoInstanceExpandedSwitch
> >> >>>>> > > >>> >
> >> >>>>> > > >>> > Then, the expansion of the ProtoBody would place a
> Switch node
> >> >>>>> > > >>> > containing all siblings which now includes the inner
> sibling Switch at
> >> >>>>> > > >>> > the end of the main scene. That sounds right to me.
> >> >>>>> > > >>> >
> >> >>>>> > > >>> > If the ProtoInstance is a sibling the first, main node,
> upon expansion
> >> >>>>> > > >>> > a potential sibling Switch would be appended after the
> siblings of the
> >> >>>>> > > >>> > first node, as another sibling, along with the main
> node:
> >> >>>>> > > >>> >
> >> >>>>> > > >>> > ProtoBody
> >> >>>>> > > >>> >   main node
> >> >>>>> > > >>> >   siblings
> >> >>>>> > > >>> >   ProtoInstance
> >> >>>>> > > >>> >
> >> >>>>> > > >>> > expansion ->
> >> >>>>> > > >>> >
> >> >>>>> > > >>> > ProtoBody
> >> >>>>> > > >>> >   main node
> >> >>>>> > > >>> >   siblings
> >> >>>>> > > >>> >   ProtoInstanceExpandedMain
> >> >>>>> > > >>> >   ProtoInstanceExpandedSwitch
> >> >>>>> > > >>> >
> >> >>>>> > > >>> > Then, the expansion of the ProtoBody would place a
> Switch node
> >> >>>>> > > >>> > containing all siblings which now includes both the
> inner main and the
> >> >>>>> > > >>> > inner sibling Switch at the end of the main scene. That
> looks also
> >> >>>>> > > >>> > reasonable at first glance.
> >> >>>>> > > >>> >
> >> >>>>> > > >>> > In that sense ProtoInstance would require ProtoDeclare
> or ProtoBody to
> >> >>>>> > > >>> > be recognized similar to Scene, for expansion purposes.
> That is
> >> >>>>> > > >>> > similar to how x-ite works. For x-ite a
> ProtoDeclaration is a
> >> >>>>> > > >>> > ExecutionContext.
> >> >>>>> > > >>> >
> >> >>>>> > > >>> > Well, I think this helped me understand Protos a bit
> better in any case,
> >> >>>>> > > >>> >
> >> >>>>> > > >>> > -Andreas
> >> >>>>> > > >>> >
> >> >>>>> > > >>> > On Fri, May 29, 2020 at 7:36 PM John Carlson <
> yottzumm at gmail.com> wrote:
> >> >>>>> > > >>> > >
> >> >>>>> > > >>> > > Don suggested a Switch node at one point (thanks Don).
> >> >>>>> > > >>> > >
> >> >>>>> > > >>> > > On Fri, May 29, 2020 at 1:28 PM Andreas Plesch <
> andreasplesch at gmail.com> wrote:
> >> >>>>> > > >>> > >>
> >> >>>>> > > >>> > >> Internal namescopes and better parsing made nested
> ProtoDeclares
> >> >>>>> > > >>> > >> inside ProtoBody and internal ROUTEs work:
> >> >>>>> > > >>> > >>
> >> >>>>> > > >>> > >>
> https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html
> >> >>>>> > > >>> > >>
> https://5ed144877a8ae8000756ddd1--x3dom.netlify.app/examples/functional/proto/inline.html
> >> >>>>> > > >>> > >>
> >> >>>>> > > >>> > >> I am still not sure how to think about multiple
> nodes in a ProtoBody
> >> >>>>> > > >>> > >> template since these are not scenes. Many examples
> seem to have only
> >> >>>>> > > >>> > >> one node, and only routes outside of it.
> >> >>>>> > > >>> > >>
> >> >>>>> > > >>> > >> Conceptually, it is pretty clear that the first node
> is THE node, and
> >> >>>>> > > >>> > >> other nodes do not render but are active and can be
> connected.
> >> >>>>> > > >>> > >>
> >> >>>>> > > >>> > >> Let's look at the Material Modulator example:
> >> >>>>> > > >>> > >>
> http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14Prototypes/MaterialModulatorIndex.html
> >> >>>>> > > >>> > >>
> >> >>>>> > > >>> > >> The main node is the Material node but then there
> are Script and
> >> >>>>> > > >>> > >> TimeSensor siblings, and routes.
> >> >>>>> > > >>> > >>
> >> >>>>> > > >>> > >> So the instance will be of Material node kind, an
> >> >>>>> > > >>> > >> X3DAppearanceChildNode. This allows the instance to
> be accepted as a
> >> >>>>> > > >>> > >> value of the Material field in an Appearance node.
> >> >>>>> > > >>> > >>
> >> >>>>> > > >>> > >> But the Script and TimeSensor sibling instances will
> not be able to
> >> >>>>> > > >>> > >> continue to live as siblings next to the instanced
> Material node since
> >> >>>>> > > >>> > >> they are not X3DAppearanceChildNodes. They will need
> to live somewhere
> >> >>>>> > > >>> > >> else but still be able to control the instanced
> Material node.
> >> >>>>> > > >>> > >>
> >> >>>>> > > >>> > >> So a straight transfer of a one to one instance to
> the scene seems out
> >> >>>>> > > >>> > >> of the question.
> >> >>>>> > > >>> > >>
> >> >>>>> > > >>> > >> I kind of hope I am missing something ? Is there
> another way to think
> >> >>>>> > > >>> > >> about Protoinstances ?
> >> >>>>> > > >>> > >>
> >> >>>>> > > >>> > >> Probably time to look at other code for inspiration.
> >> >>>>> > > >>> > >>
> >> >>>>> > > >>> > >> -Andreas
> >> >>>>> > > >>> > >>
> >> >>>>> > > >>> > >> On Fri, May 29, 2020 at 8:39 AM Andreas Plesch <
> andreasplesch at gmail.com> wrote:
> >> >>>>> > > >>> > >> >
> >> >>>>> > > >>> > >> > I added a few more Proto test examples to
> >> >>>>> > > >>> > >> >
> >> >>>>> > > >>> > >> >
> https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html
> >> >>>>> > > >>> > >> >
> >> >>>>> > > >>> > >> > and
> >> >>>>> > > >>> > >> >
> >> >>>>> > > >>> > >> >
> https://5ed100c873166e0006438ab0--x3dom.netlify.app/examples/functional/proto/inline.html
> >> >>>>> > > >>> > >> >
> >> >>>>> > > >>> > >> > That includes a NIST example which uses internal
> routing and one which
> >> >>>>> > > >>> > >> > has ProtoDeclare inside ProtoBody, nested five
> deep. These are good
> >> >>>>> > > >>> > >> > targets to get to work before thinking about
> fields and interface.
> >> >>>>> > > >>> > >> >
> >> >>>>> > > >>> > >> >
> https://www.web3d.org/x3d/content/examples/ConformanceNist/Miscellaneous/PROTO/index.html
> >> >>>>> > > >>> > >> >
> >> >>>>> > > >>> > >> > -Andreas
> >> >>>>> > > >>> > >> >
> >> >>>>> > > >>> > >> > On Thu, May 28, 2020 at 8:35 PM Andreas Plesch <
> andreasplesch at gmail.com> wrote:
> >> >>>>> > > >>> > >> > >
> >> >>>>> > > >>> > >> > > It turns out that github pages does not like
> serving all the little js
> >> >>>>> > > >>> > >> > > files making up x3dom separately.
> >> >>>>> > > >>> > >> > >
> >> >>>>> > > >>> > >> > > Here is a complete build with the example:
> >> >>>>> > > >>> > >> > >
> >> >>>>> > > >>> > >> > >
> https://5ed055bd4da4fa0007bf3d0a--x3dom.netlify.app/examples/functional/proto/inline.html
> >> >>>>> > > >>> > >> > >
> >> >>>>> > > >>> > >> > > -Andreas
> >> >>>>> > > >>> > >> > >
> >> >>>>> > > >>> > >> > >
> >> >>>>> > > >>> > >> > >
> >> >>>>> > > >>> > >> > > On Thu, May 28, 2020 at 6:43 PM Andreas Plesch <
> andreasplesch at gmail.com> wrote:
> >> >>>>> > > >>> > >> > > >
> >> >>>>> > > >>> > >> > > > 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
> >> >>>>> > > >>> > >> > >
> >> >>>>> > > >>> > >> > >
> >> >>>>> > > >>> > >> > >
> >> >>>>> > > >>> > >> > > --
> >> >>>>> > > >>> > >> > > Andreas Plesch
> >> >>>>> > > >>> > >> > > Waltham, MA 02453
> >> >>>>> > > >>> > >> >
> >> >>>>> > > >>> > >> >
> >> >>>>> > > >>> > >> >
> >> >>>>> > > >>> > >> > --
> >> >>>>> > > >>> > >> > Andreas Plesch
> >> >>>>> > > >>> > >> > Waltham, MA 02453
> >> >>>>> > > >>> > >>
> >> >>>>> > > >>> > >>
> >> >>>>> > > >>> > >>
> >> >>>>> > > >>> > >> --
> >> >>>>> > > >>> > >> Andreas Plesch
> >> >>>>> > > >>> > >> Waltham, MA 02453
> >> >>>>> > > >>> >
> >> >>>>> > > >>> >
> >> >>>>> > > >>> >
> >> >>>>> > > >>> > --
> >> >>>>> > > >>> > Andreas Plesch
> >> >>>>> > > >>> > Waltham, MA 02453
> >> >>>>> > > >>>
> >> >>>>> > > >>>
> >> >>>>> > > >>>
> >> >>>>> > > >>> --
> >> >>>>> > > >>> Andreas Plesch
> >> >>>>> > > >>> Waltham, MA 02453
> >> >>>>> > >
> >> >>>>> > >
> >> >>>>> > >
> >> >>>>> > > --
> >> >>>>> > > Andreas Plesch
> >> >>>>> > > Waltham, MA 02453
> >> >>>>> >
> >> >>>>> >
> >> >>>>> >
> >> >>>>> > --
> >> >>>>> > Andreas Plesch
> >> >>>>> > Waltham, MA 02453
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>> --
> >> >>>>> Andreas Plesch
> >> >>>>> Waltham, MA 02453
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> --
> >> >>>> Andreas Plesch
> >> >>>> Waltham, MA 02453
> >> >>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>> Andreas Plesch
> >> >>> Waltham, MA 02453
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Andreas Plesch
> >> >> Waltham, MA 02453
> >>
> >>
> >>
> >> --
> >> Andreas Plesch
> >> Waltham, MA 02453
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20220110/1b2ebe5c/attachment-0001.html>