[x3d-public] [x3dom-users] Cobweb_dom...Script Magic? Loading DOM subscenes after parent in X3DOM and Cobweb. ALMOST complete, requires sequencing of outer functions.
Joe D Williams
joedwil at earthlink.net
Wed May 31 10:45:30 PDT 2017
> I have not been convinced that Protos need to exist in an HTML
environment.
Well, i guess you don't have any example you like that use protos. I
suggest more study.
> if you path is to implement Protos on the way to implementing
> Scripts,
> you need to solve the entire Script problem first.
Why bother telling someone who is actually doing some work how the
problem must be solmved. Protos don't need scripts to operate yet can
still be very usefull.
> I think something like a macro expansion ...
well, show your design and we will see if we can help you get it
working.
Joe
----- Original Message -----
From: "Leonard Daly" <Leonard.Daly at realism.com>
To: "John Carlson" <yottzumm at gmail.com>
Cc: <x3dom-users at lists.sourceforge.net>; "X3D Graphics public mailing
list" <x3d-public at web3d.org>; "Andreas Plesch"
<andreasplesch at gmail.com>
Sent: Monday, May 22, 2017 7:06 AM
Subject: Re: [x3d-public] [x3dom-users] Cobweb_dom...Script Magic?
Loading DOM subscenes after parent in X3DOM and Cobweb. ALMOST
complete, requires sequencing of outer functions.
> John,
>
> I have not been convinced that Protos need to exist in an HTML
> environment. Scripts are an integral piece of the Proto architecture
> so
> if you path is to implement Protos on the way to implementing
> Scripts,
> you need to solve the entire Script problem first. If Scripts are
> optional, then why have Proto? I think something like a macro
> expansion
> can solve all of the use cases where Proto would be used while being
> lighter weight and easier to implement and possibly use.
>
> Leonard Daly
>
>
>> Leonard, I believe Scripts should be implemented AFTER Protos.
>> Just
>> my opinion. Once the Protos and the ROUTEs and the Scripts are
>> expanded with the new DEFs, then you apply the event model. This
>> makes things easier, but takes more memory. Then you optimize.
>> Beware premature optimization.
>>
>> John
>>
>> On May 21, 2017 12:16 AM, "Leonard Daly" <Leonard.Daly at realism.com
>> <mailto:Leonard.Daly at realism.com>> wrote:
>>
>> John,
>>
>> I don't really like to answer this way, but why?
>>
>> X3DOM does not have Proto/ExternProto feature. It does not have
>> X3D Script node. The integration with HTML is too close to
>> allow
>> an X3D Script node. HTML JavaScript (via DOM and X3D node
>> manipulation) is available and used extensively. X3DOM does not
>> handle VRML (meaning a text file with {} syntax). There is an
>> unofficial JSON loader. Perhaps you have one too. How does it
>> get
>> the scene graph into DOM? Does it create DOM elements (or
>> perhaps
>> an HTML text string which is then parsed)? Something else?
>>
>> To the extent I understand your question, you are asking for
>> help
>> in constructing a means of handling X3D Script node in X3DOM.
>> Once
>> that is done, Proto/ExternProto would be next. This would all
>> come
>> into the browser through an JSON encoded file. It seems to me
>> that
>> trying to handle X3D Script code requires an entire
>> infrastructure
>> supporting the X3D event mode and calling script code with X3D
>> arguments. It also requires building full support for SAI and
>> supporting the 'directOutput' field. That is a major effort
>> with
>> no obvious purpose that I see in V4.
>>
>> You are asking for some serious time support (I think) into an
>> application that is neither fully X3D-compliant, nor
>> DOM-compliant
>> (but the closest to both that is available). At least for me, I
>> do
>> not understand how this effort would further an X3D integrated
>> DOM
>> system. I am quite willing to listen to your reasons and help
>> where I can, but I would like to see where this is going first.
>>
>> Leonard Daly
>>
>> P.S. Everything above is for client-side code. Server side
>> code
>> can manipulate things as much as it wants to create something
>> that
>> runs in a client-side browser.
>>
>> P.P.S. I do think there is a need to JSON encoding in V4
>> subject
>> to the node definition for V4.
>>
>>
>>
>>> Yes, Leonard, for quite some time I have an X3D JSON
>>> PROTOtypeExpander.js that works with X3D PROTOs and
>>> EXTERNPROTOs
>>> and displays in X3DOM. I don’t know how complete it is, and
>>> testers are welcome. My EXTERNPROTO expander runs on the
>>> server,
>>> so is not included in the message, but it is included in the
>>> link
>>> in the original message. If someone can make the EXTERNPROTO
>>> expander work client side that would be great.
>>>
>>> The EXTERNPROTO expander is generally called like:
>>>
>>> json = externPrototypeExpander(outfile, json);
>>>
>>> Where json is the parent json of the extern, and outfile is
>>> the
>>> parent X3D file being loaded (I think “” will probably do in a
>>> pinch. I am not sure.). The extern PROTOs will be included
>>> in
>>> the original JSON as a ProtoDeclare object. You may have to
>>> run
>>> the flattener afterwards, and it is run as:
>>>
>>> json = flattener(json);
>>>
>>> It removes empty objects from the JSON.
>>>
>>> Yes, I would like someone to help me with VRMLScript for
>>> X3DOM,
>>> if someone is available. I have a very barebones and
>>> incorrect
>>> implementation here:
>>>
>>>
>>> https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/node/Script.js
>>>
>>> <https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/node/Script.js>
>>>
>>> Please help. I don’t know the X3D event model, and I’m not
>>> likely to learn soon. The X3D event model can be emulated in
>>> Browser-side JavaScript, but there’s only Cobweb for proof.
>>>
>>>
>>> I have another version of flipper.html here that works with
>>> X3DOM
>>> and Cobweb adding the subscene later. It works with Promises,
>>> but the functions still aren’t separated…close, but no cigar.
>>> Take a look:
>>>
>>>
>>> https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/html/flipper.html
>>>
>>> <https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/html/flipper.html>
>>>
>>> Sorry, I tend to use the XML version of “Proto”, and not the
>>> VRML
>>> “PROTO”.
>>>
>>> X3DJSONLD provides an infrastructure for X3D JSON Browser
>>> development, including X3D XML -> X3D JSON conversion on the
>>> server, and X3D JSON to X3D XML loading into X3DOM and Cobweb.
>>> It also includes conversions from XML DOM to Java and Nashorn
>>> JavaScript for X3DJSAIL app development.
>>>
>>> There is definite potential for an XML PROTO expander, as I
>>> have
>>> written this code, but not seriously tested:
>>>
>>>
>>> https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/node/CompleteXMLPrototypeExpander.js
>>>
>>> <https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/node/CompleteXMLPrototypeExpander.js>
>>>
>>> So far, it’s still server-side. If you’re going to modify it,
>>> split it into server and client-side pieces, please. Complete
>>> is
>>> probably a misnomer…
>>>
>>> Thanks,
>>>
>>> John
>>>
>>> Sent from Mail
>>> <https://go.microsoft.com/fwlink/?LinkId=550986>
>>> for Windows 10
>>>
>>> *From: *Leonard Daly <mailto:Leonard.Daly at realism.com>
>>> *Sent: *Saturday, May 20, 2017 7:17 PM
>>> *To: *John Carlson <mailto:yottzumm at gmail.com>; Andreas Plesch
>>> <mailto:andreasplesch at gmail.com>; holger.seelig at yahoo.de
>>> <mailto:holger.seelig at yahoo.de>
>>> *Cc: *x3dom-users at lists.sourceforge.net
>>> <mailto:x3dom-users at lists.sourceforge.net>; X3D Graphics
>>> public
>>> mailing list <mailto:x3d-public at web3d.org>
>>> *Subject: *Re: [x3dom-users] Cobweb_dom...Script Magic?
>>> Loading
>>> DOM subscenesafter parent in X3DOM and Cobweb.
>>>
>>> John,
>>>
>>> Cobweb_dom, X3DOM experts, I need some help adding a child
>>> DOM scenegraph with prototypes to a parent DOM scenegraph
>>> after the
>>>
>>>
>>> Not sure how any of this applies to X3DOM as it does not have
>>> PROTOs. Assuming you mean X3D prototypes via PROTO or
>>> EXTERNPROTO. If you mean something else, please elaborate.
>>>
>>>
>>> Leonard Daly
>>>
>>>
>>>
>>>
>>> primary scene has been loaded, and not before. I have an
>>> example of loading before the scene is loaded, and in a
>>> callback. If you have an example with Promises instead of
>>> callback nesting, that would be more ideal, the second
>>> $.getJSON() (child scenegraph) might finish before the
>>> first
>>> $.getJSON() (parent scenegraph) if I don’t use promises or
>>> callback nesting. Also, Promises would allow me to
>>> separate
>>> the parent loading somewhat from the child loading, and
>>> create separate functions. Also, X3DOM experts can
>>> provide
>>> an example with Promises as well. Meanwhile, I will be
>>> reading about Promises.
>>>
>>> Here is my example so far:
>>>
>>>
>>> https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/html/flipper.html
>>>
>>> <https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/html/flipper.html>
>>>
>>> Viewable here:
>>>
>>>
>>> https://coderextreme.net/X3DJSONLD/src/main/html/flipper.html
>>>
>>> <https://coderextreme.net/X3DJSONLD/src/main/html/flipper.html>
>>>
>>> The white Box is the subscene of the dolphin scene.
>>>
>>> The following related code is from
>>>
>>> https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/node/loaderJQuery.js
>>>
>>> <https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/node/loaderJQuery.js>
>>>
>>> and references code from:
>>>
>>>
>>> https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/node/X3DJSONLD.js
>>>
>>> <https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/node/X3DJSONLD.js>
>>>
>>> [ actually, I think the last two reference each other –
>>> naughty ]
>>>
>>> Data is here:
>>>
>>> [ child scenegraph ]
>>>
>>>
>>> https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/data/abox.json
>>>
>>> <https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/data/abox.json>
>>>
>>> [ parent scenegraph ]
>>>
>>>
>>> https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/data/flipp.json
>>>
>>> <https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/data/flipp.json>
>>>
>>> Cobweb doesn’t need the prototypeExpander or the flattener
>>> (well, it might have with prototypes in cobweb_dom, but I
>>> think the last release fixed that…haven’t checked—here is
>>> a
>>> good test for you!). This is a dual example, and I haven’t
>>> figured out how to conditionally run the prototypeExpander
>>> on
>>> only X3DOM code. Please test without the
>>> PrototypeExpander.js and Flattener.js included, and remove
>>> X3DOM, since it won’t work in that case. X3DOM folks can
>>> include the two JavaScript files which are here:
>>>
>>>
>>> https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/node/PrototypeExpander.js
>>>
>>> <https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/node/PrototypeExpander.js>
>>>
>>>
>>> https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/node/Flattener.js
>>>
>>> <https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/node/Flattener.js>
>>>
>>> You may provide your own appendInline (below) which doesn’t
>>> call loadSchema. That may be too complex of a download.
>>> That is, you probably don’t want to do all that JSON
>>> schema
>>> validation in your example. Try to keep my code close to
>>> what it is otherwise.
>>>
>>> And if you start supporting X3D JSON in your viewers, that
>>> would be even better!
>>>
>>> John
>>>
>>> /**
>>>
>>> ·Next is passed the element parameter
>>>
>>> ·*/
>>>
>>> function appendInline(element, url, next) {
>>>
>>> $.getJSON(url, function(json) {
>>>
>>> if (typeof prototypeExpander === 'function') {
>>>
>>> json = prototypeExpander(url, json, "");
>>>
>>> } else {
>>>
>>> console.error("Perhaps you need to include the
>>> PrototypeExpander.js?");
>>>
>>> }
>>>
>>> if (typeof flattener === 'function') {
>>>
>>> json = flattener(json);
>>>
>>> } else {
>>>
>>> console.error("Perhaps you need to include the
>>> Flattener.js?");
>>>
>>> }
>>>
>>> // must validate here because we call an inner
>>> method.
>>>
>>> loadSchema(json, url, doValidate, function() {
>>>
>>> ConvertToX3DOM(json["X3D"]["Scene"], "Scene", element,
>>> url);
>>>
>>> next(element);
>>>
>>> }, function(e) {
>>>
>>> console.error(e);
>>>
>>> });
>>>
>>> }).fail(function(jqXHR, textStatus, errorThrown) {
>>> alert('getJSON request failed! ' + textStatus + ' ' +
>>> errorThrown); });
>>>
>>> }
>>>
>>> /**
>>>
>>> ·Next is passed the selected element from selector
>>>
>>> ·Selector is the CSS selector to append inline to.
>>>
>>> ·*/
>>>
>>> function loadSubscene(selector, url, next) {
>>>
>>> appendInline(document.querySelector(selector), url, next);
>>>
>>> }
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> Check out the vibrant tech community on one of the world's
>>> most
>>>
>>> engaging tech sites, Slashdot.org!http://sdm.link/slashdot
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> X3dom-users mailing list
>>>
>>> X3dom-users at lists.sourceforge.net
>>> <mailto:X3dom-users at lists.sourceforge.net>
>>>
>>> https://lists.sourceforge.net/lists/listinfo/x3dom-users
>>> <https://lists.sourceforge.net/lists/listinfo/x3dom-users>
>>>
>>> --
>>> *Leonard Daly*
>>> 3D Systems & Cloud Consultant
>>> LA ACM SIGGRAPH Chair
>>> President, Daly Realism - /Creating the Future/
>>>
>>
>> --
>> *Leonard Daly*
>> 3D Systems & Cloud Consultant
>> LA ACM SIGGRAPH Chair
>> President, Daly Realism - /Creating the Future/
>>
>
> --
> *Leonard Daly*
> 3D Systems & Cloud Consultant
> LA ACM SIGGRAPH Chair
> President, Daly Realism - /Creating the Future/
>
--------------------------------------------------------------------------------
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
More information about the x3d-public
mailing list