[x3d-public] [x3dom-users] Testing JSON protos with dev X3DOM

Andreas Plesch andreasplesch at gmail.com
Thu Jun 25 19:23:00 PDT 2020


Hi John,

I am using the gh-pages branch in andreasplesch/x3dom for proto work
since github pages makes it easier to use the devtools in the browser
for development. I just committed an update for ExternProtoDeclare
which starts to work now as well:
https://andreasplesch.github.io/x3dom/test/functional/proto/inline.html

Most related code is in NodeNameSpace.js, but the addChild function
for X3DNode.js also needed an update. This is actually where the
protoinstance node gets substituted by protobody based nodes.

ProtoDeclare and ProtoInstance parsing is using the dom. So as long as
the JSON gets properly translated into a dom, it might just work.

The basic flow is to first prepare a ProtoDeclare by some parsing and
storing IS connections. Then the prepared declaration is used to
register a new x3dom node type which has the new fields. The
registration is just like a regular node registration but more
generalized. Then for each ProtoInstance a dom node is constructed
with the new node as tagname and populated fields as attributes,
including node fields as children. The constructed dom node is added
to the dom scene and x3d scene which triggers generating the protobody
based 'real' nodes and linking events to them and out of them (in
nodeChanged). That is mostly it. There are quite a few mind benders to
ensure proper namescoping, event flow and nesting.

ExternProto initially just puts a placeholder in the proto list. Then
when a protoinstance needs it, it loads the protodeclare from the url,
and then treats it like a normal protodeclare but with the new name.
The js async loading makes it a bit hairy since the sequencing is
harder. For example, there is a small problem with ExternProto in an
Inline with namespacename since the Inline scene dom can get
transferred to the main dom before the protoinstance has a chance to
be added to the inline scene dom. ExternProto is also where JSON
support would need to be added. Essentially, instead of using the
browser DomParser to generate a dom from the loaded xml string, a JSON
parser would need to generate the same dom, similar to the Inline json
loading. So probably first a js object from the JSON string, and then
a dom from the js object. Actually, the response object from the fetch
api call, directly has a .JSON() (or similar) method to parse into a
js object.

It should be possible to recognize the #name syntax for the
ExternProto urls which I will do next. The NIST Proto examples have
some rules for those although I think these rules are not necessarily
spec. based but common sense derived. Then some error checking and
perhaps adding the rotor example after descripting it. Also, field
access types are currently not used but could be checked quite
straightforwardly in some cases for event routing. ExternProtoDeclare
fields are also ignored, and instead only the referenced ProtoDeclare
fields are used. I am still not quite sure what these
ExternProtoDeclare fields are for.

Please feel free to fork, and pull. Make sure you do it in the right
direction, eg. towards your own repo.

Thank you for your interest, -Andreas

On Thu, Jun 25, 2020 at 9:04 PM John Carlson <yottzumm at gmail.com> wrote:
>
> Sometime I would like to test JSON protos with the new proto handler.
>
> I think may involve further modification of X3DOM, at least removal of the JSON proto expander from the code.
>
> I will need to do a pull request from a branch (recommendations?) and then proceed to make changes.
>
> John
> _______________________________________________
> X3dom-users mailing list
> X3dom-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/x3dom-users



-- 
Andreas Plesch
Waltham, MA 02453



More information about the x3d-public mailing list