[x3d-public] VRMLScripting in x3dom

[John Carlson]

The important thing about bringing VRMLScripting into X3DOM is that the Script tag (whatever we call it) itself doesn’t matter. What matters is the <field>s for ROUTEs, and how we send values from fields to VRMLScript and back.   So let’s focus on <field>s instead of <Script>, <script>, etc.  We need the Script fields to react to the rest of the event framework in X3DOM, so we don’t have to set up a whole new eventing framework for VRMLScript in X3DOM.

Let’s assume that the Script tag naming solution is solved, and proceed with supporting the stuff around it.

I do think that Scripts may need to be duplicated in the Proto Expander if the Scripts appear in a Proto (how do we want to handle Protos in X3DOM?), but would like more feedback on this subject (why must Scripts be done before Protos?) from Leonard.

Here’s a concrete example if we want to discuss it:

https://coderextreme.net/X3DJSONLD/src/main/html/index.html

select ./data/bubs.json in the upper left pulldown.

Here’s the data before processing by the client:

https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/data/bubs.json

I am *not* saying my solution is a good one (yet). I need to avoid evals, and have been thinking about that.  However,
If we take my event loop out of the question, and just use X3DOM’s event loop, I think my 3 eval problem can be converted to a single new Function() (scoping issue solved). Another thing that might solve my problem is nesting new Function() – what do you think? Hmm.

Note that both x_ite and x3dom use eval in the versions I am looking at.  We’re not doing too well at listening to Leonard.

We also need to think about applications which support multiple canvases with same or similar X3D file showing, and how to manage ROUTEs and Scripts with that.  I have been putting some thinking behind that. See:

https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/node/Script.js

see “class Scripts”, loadScripts takes X3D data, a selector to make it unique on the page, and a url to distinguish files (say an XML and JSON file with same selector and different URL).

I would love for some one to take over some responsibility for Script.js in the X3DOM community. It’s a WIP.

Also, for Scripting we need to make sure that id’s are unique on the page. If we load the same file In X3DOM and X_ITE, how do we support JavaScript referencing an id through the DOM API?  How do we handle DEF when we load the same file in 2 different browsers on a web page?   What if there’s JavaScript DOM on the page which references the DEF?

This is why we need careful thinking (thanks Leonard), especially when it comes to loading the same file more than once on a page.

I think we can use X3DJSONLD to experiment with some of these issues, and Leonard has ferreted out some of the problems, but there’s probably more.

I would like to emphasize again is that the Script fields are what we need to focus on what we need to get into x3dom.  I think it might get rid of my reason for messing with scripts altogether, or for the most part.  I think we might need ROUTEs to work with JavaScripts, if there’s a plan to do that.

If there are good reasons NOT to support VRMLscripting, these need to be supported with reasons, not just affirmations.   We need to be notified of security and technical reasons for sure.

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20190130/6aa06685/attachment.html>