[x3d-public] MFString (and ultimately SFString) Routes with JS Proxy

[yottzumm at gmail.com]

This version works with multiple routes on a fromProxy.

https://github.com/coderextreme/X3DJSONLD/blob/master/route.js

Good bug hunting!

This is still low level code.  I think I could add a SAI addRoute() on top of this, but likely, I would have to provide a map from Node to proxy and proxyAction somewhere hidden or put the proxy and proxyAction in the Node.  Then setNodeField() in the test code would be passed the Node, and you could look up the proxy and proxy action based on the Node and call setField().  This is an enhancement I will consider.

This all probably means that I would have to start using the Map object to map object to object, if I don’t modify the nascient Node.  Or I can use DEF values for keys for nodes.  Hmm.  Perhaps I should start making this more X3D dependent.

John

Sent from Mail for Windows 10

From: yottzumm at gmail.com
Sent: Monday, April 17, 2017 11:37 PM
To: Andreas Plesch
Cc: X3D Graphics public mailing list
Subject: MFString (and ultimately SFString) Routes with JS Proxy

I don’t have any translation in mind for this code, but it may be possible to write ROUTEs which do translation.  I am not really sure yet.  I think I would need more advanced selectors.  I am not ruling translation out at this point, even possibly transferring functions between VRML Scripts.  I am still working on base functionality.

The possible advantage of getField() or setField() over standard JavaScript accessors is that you can change the selector (in any desirable language) to a proxy property more amenable to JavaScript explicitly, instead of automatically, and still have the advantage of a single proxy for a hierarchy (with single property proxies).  That’s my thoughts anyway.  I am going to move away from the SFString code and go back to the MFString code.  It seems more valuable now.  You can always add extra quotes around an SFString to make it an MFString, I think, if parsing won’t work.  I will be removing singleroute.js as soon as I can translate the test over.

getField() may become a bit like document.querySelectorAll().  I haven’t given it enough thought yet.

I think I might be writing a selector language for JSON to make it more X3D-like, with MFStrings, and also, implement VRML script events for X3DOM ultimately (that’s why it’s part of X3DJSONLD).  I am not sure of the actual purpose this might serve yet, so I am trying to keep it general, and I’m having fun with proxies.  I think about setField() with a selector of ‘”A” “0” “addChildren”’ to add a value or values to the end of an MFNode.  That will be in the future.

Not that it does all this yet 😊.  Actually, I don’t even know how much of this is already implemented in JavaScript for JSON…please inform.

I don’t want to use DOM because of extra properties and unserializability at this point.  I am not sure I will achieve this goal.

I changed the subject to be more inline with what I am intending.  Ultimately, I want it to work with SFString toField an fromField as well, but that may be a simple simplification of the code.

I still have yet to deal with fromNode and toNode as SFStrings.

John

Sent from Mail for Windows 10

From: Andreas Plesch
Sent: Monday, April 17, 2017 11:47 AM
To: John Carlson
Cc: X3D Graphics public mailing list
Subject: Re: Routes with JS Proxy

Hi John,

I do plan to look at the code and understand it better, ideally in the context of a simple json encoded x3d scene though it may be some time.

To recap, I think the idea is to perhaps use this to have a dynamically updating scene as json (or js?) object which then would be (dynamically?) translated to a-frame (or x3dom, or cobweb?) ?

Since you mentioned proxied get functions, an idea may be to use the proxy to transparently return actual field values rather than strings( or arrays, or numbers) though I am not sure if there is an advantage over having an explicit getField function.

-Andreas


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170418/51799326/attachment.html>