<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:2001343371;
mso-list-template-ids:-1;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style></head><body lang=EN-US link=blue vlink="#954F72"><div class=WordSection1><p class=MsoNormal>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.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>getField() may become a bit like document.querySelectorAll(). I haven’t given it enough thought yet.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.</p><p class=MsoNormal><br>Not that it does all this yet <span style='font-family:"Segoe UI Emoji",sans-serif'>😊</span>. Actually, I don’t even know how much of this is already implemented in JavaScript for JSON…please inform.</p><p class=MsoNormal><br>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.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I still have yet to deal with fromNode and toNode as SFStrings.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>John</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Sent from <a href="https://go.microsoft.com/fwlink/?LinkId=550986">Mail</a> for Windows 10</p><p class=MsoNormal><o:p> </o:p></p><div style='mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='border:none;padding:0in'><b>From: </b><a href="mailto:andreasplesch@gmail.com">Andreas Plesch</a><br><b>Sent: </b>Monday, April 17, 2017 11:47 AM<br><b>To: </b><a href="mailto:yottzumm@gmail.com">John Carlson</a><br><b>Cc: </b><a href="mailto:x3d-public@web3d.org">X3D Graphics public mailing list</a><br><b>Subject: </b>Re: Routes with JS Proxy</p></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>Hi John,</p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.</p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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?) ?</p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.</p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>-Andreas</p></div></div><p class=MsoNormal><o:p> </o:p></p></div></body></html>