[x3d-public] Script Illustrative Example [was: X3D Specification Relationships diagram]

[Andreas Plesch]

I went back to the cobweb repo to very carefully read through the rather
mind bending script node code in

https://github.com/create3000/cobweb/blob/master/cobweb.js/cobweb/Components/Scripting/Script.js

and came to the conclusion that the x3d scripts are only evaled once during
initialization, contrary to what I had thought. The script text is cleverly
appended with an array of all defined named functions which then becomes
the return value of the eval call. These functions are then stored in a
local scope this.context object, essentially as methods. Then, whenever a
lifecycle function or a field function needs to be executed, the context
method is called.

One could probably expose this context object and then redefine its methods
from Dom scripts. However, one would lose the cobweb constructed "with"
"global" object which allows easy and standard access to x3d functions and
user defined fields. It could be probably reconstructed if needed.

I may try to convert the example to cobweb dom.

Andreas

-The formatting survived the direct mail but not the route through the list
probably because I receive digests.


On Aug 11, 2017 9:03 PM, "Leonard Daly" <Leonard.Daly at realism.com> wrote:

I was asked by John to construct an example illustrating the items listed
below. I also have replies to Andreas' comments. The original message is at
the bottom (for reference). I've copied the relevant questions/statements
to the top to make reading easier.

First to the example. It is located at http://tools.realism.com/
development/WG-Support/2017-08-09/ScriptIllustration.html
It does not use Cobweb since I can't begin to figure out how to do this in
Cobweb. OTOH, if X3D is DOM integrated, then the it shouldn't matter where
various functions and methods are located.

The example is strictly 2D, but I think it clearly illustrates the goal.
The default Y interpolator is nothing (no change). Selecting different
buttons change the interpolator in real-time. Each interpolator is defined
as a function. The variable 'changeY' holds the current interpolator. When
a button is pressed, the value of 'changeY' is set to the selected
interpolator. There is no 'case' statement the uses the correct
interpolator on each pass through the animation loop.

John if this doesn't illustrate the concept, please explain what you need
to see.

Andreas, you have done and continue to do a lot in support of web 3D,
especially wrt to X3DOM. I continue to be impressed with your solutions to
problems presented to that list. [I'll have one soon, with a potential
solution.]


AP: Mixing DOM and x3d scripts is inherently problematic since x3d scripts
expect their own environment (scope). But let's see.

AP: Not sure if x3d scripts should be available globally, eg. as window.foo
which means foo is global. This would mean that any other script or
framework needs to be careful not to use the same function names.

AP: window.x3d should be nicer, as a dedicated namespace. x3dom uses the
x3dom namespace.

If X3D and HTML are fully integrated then they will be mixed. It is now
common practice to put library methods into their own namescope. This
namescope is not limited, but is prefixed by a known library label (e.g.,
x3dom, THREE, etc.). Mandating that X3D in HTML use the 'x3d' namescope
would cause problems if someone wanted to run two different libraries from
the same HTML context. iframe can fix that, but it seems overly restrictive.


function bar(event, time) {
>      window.foo = bar;            // I would (perhaps) settle for
> window.x3d.foo = bar;
> }
>
>
AP: This currently does not work since cobweb goes back to the original
function source each time the script is run. But the x3d script could
probably use internally a global HTML script function which can be
redefined at will, to enable a hook into an x3d script.

[1]

<Script ...>    <!-- X3D Script node -->
     function foo (event, time) {
         window.bar = foo;
     }
</script>


AP: This probably already works since cobweb evals the function text almost
as is.

Is this the same as

[2]

var foo = function (event, time) {do_work;};
window.bar = foo;

 ?

It seems to me that eval the script text each time, especially in an
animation loop, is needlessly expensive.
The two examples (indented if that works in your mail reader) are not the
same. The first example sets window.bar to be 'foo' each time it runs. The
second example only sets window.bar to be 'foo' after the definition is
processed. If there is something else setting window.bar after the 'foo'
function definition is processed, then that definition to 'foo' is never
used.


AP: What does the SAI say about manipulating or calling x3d script
functions from the outside ? You may only be able to remove and add
complete script nodes but not work with the script functions ?

AP: Proposed text would be great. For now, it may be productive to settle
for slightly less integration by keeping x3d scripts pretty much internal
to the x3d context but allow x3d scene control via the DOM, eg. make x3d
nodes similar to svg/html elements.


This is my main point. DOM is an API. If X3D chooses to define an API in
HTML, then it must be done so as not to interfere with the DOM API.
Developers will use the DOM API to do things anyway. X3D should only expand
on that, not restrict that. Anything less would not be full integration.
There is no such thing as an SVG Script tag. It is located in the same
space all all HTML scripts.


Leonard Daly

P.S. I hope all of the formatting and styling worked.






On 8/11/2017 7:33 AM, Andreas Plesch wrote:

Date: Thu, 10 Aug 2017 18:31:25 -0700
> From: Leonard Daly <Leonard.Daly at realism.com>
> To: John Carlson <yottzumm at gmail.com>, X3D Graphics public mailing
>         list <x3d-public at web3d.org>, Web3D Consortium <
> consortium at web3d.org>
> Cc: X3D Graphics Working Group <x3d at web3d.org>
> Subject: Re: [x3d-public] [x3d] X3D Specification Relationships
>         diagram
>

Leonard, thanks for raising this, and I appreciate your attempt to rally
broader support around v4 and web compatibility. I continue to do what I
can which is not too much these days.

On 8/10/2017 5:17 PM, John Carlson wrote:
> >
> > Leonard wrote:
> >
> > >and node name collisions (i.e., Script).
> >
> > There has been quite a bit of progress with this and X3DJSONLD and
> > X3DOM. It?s been under the covers because I have not advertised it
> > much. I have several scripts running, but not the full complement of
> > my examples.  It does not run the X3D event model yet, except for
> > initialize().
> >
> > Cobweb of course, already handles this, so quit bellyaching.
> >
>
> Cobweb even with Andreas' DOM interface extensions does not integrate
> with the DOM regarding Scripts. A full integration would allow the
> following:
>
>
Mixing DOM and x3d scripts is inherently problematic since x3d scripts
expect their own environment (scope). But let's see.


> X3D Script function called 'foo'
> HTML script function called 'bar'
>
> In the body of bar, I should be able to redefine 'foo'. It is (in a
> fully integrated system) available as window.foo. Similarly for inside
> of 'foo' to change 'bar'.
>
>
Not sure if x3d scripts should be available globally, eg. as window.foo
which means foo is global. This would mean that any other script or
framework needs to be careful not to use the same function names.


> function bar(event, time) {
>      window.foo = bar;            // I would (perhaps) settle for
> window.x3d.foo = bar;
> }
>
>
window.x3d should be nicer, as a dedicated namespace. x3dom uses the x3dom
namespace.

This currently does not work since cobweb goes back to the original
function source each time the script is run. But the x3d script could
probably use internally a global HTML script function which can be
redefined at will, to enable a hook into an x3d script.

and
>
> <Script ...>    <!-- X3D Script node -->
>      function foo (event, time) {
>          window.bar = foo;
>      }
> </script>
>
>
This probably already works since cobweb evals the function text almost as
is.

Is this the same as

var foo = function (event, time) {do_work;};
window.bar = foo;
 ?

I should be able to construct an object with 'foo' as a method. E.g.,
>
> var globalVar = {};
> globalVar.x3d = foo;
>
> // should call the X3D script passing it a reference to the current
> value of 'event' and 'time'.
> globalVar.x3d(event, time);
>
>
It may be possible to 'export' named x3d script functions to window.x3d, so
they can be called. cobweb would currently redefine a named function each
time an x3d script is executed.


> Inside 'foo' I should be able to access any DOM element to get it's
> current state or even establish an event listener.
>

You should be able to do that in cobweb now although it would be strange to
find DOM code in an X3D script. Perhaps for HUD of GUI purposes it could be
useful, actually.


> I know there are some things that Cobweb can do, but there has been no
> discussions in the WG for the language that would be necessary to ensure
> HTML/DOM/X3D interaction like I described above.
>

What does the SAI say about manipulating or calling x3d script functions
from the outside ? You may only be able to remove and add complete script
nodes but not work with the script functions ?


> Unrolling scripts on the server (or at least not in the runtime of the
> browser) is all fine and good, but again there has been no discussion in
> the WG as to how to even approach writing that up.
>
> I will be happy to be (relatively) quiet on these points if someone can
> show me working examples and proposed text to make this work.
>

Proposed text would be great. For now, it may be productive to settle for
slightly less integration by keeping x3d scripts pretty much internal to
the x3d context but allow x3d scene control via the DOM, eg. make x3d nodes
similar to svg/html elements.

-Andreas


>
> --
> *Leonard Daly*
> 3D Systems & Cloud Consultant
> LA ACM SIGGRAPH Chair
> President, Daly Realism - /Creating the Future/
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments
> /20170810/93cc05ca/attachment.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
> ------------------------------
>
> End of x3d-public Digest, Vol 101, Issue 9
> ******************************************


-- 
Andreas Plesch
39 Barbara Rd.
Waltham, MA 02453


_______________________________________________
x3d-public mailing
listx3d-public at web3d.orghttp://web3d.org/mailman/listinfo/x3d-public_web3d.org


-- 
*Leonard Daly*
3D Systems & Cloud Consultant
LA ACM SIGGRAPH Chair
President, Daly Realism - *Creating the Future*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170812/5cf72f23/attachment-0001.html>