[x3d-public] X3D-HTML event passing, let's look at simplest aspects first
Leonard Daly
Leonard.Daly at realism.com
Mon Mar 4 07:33:11 PST 2019
John,
> So here’s the problem I think. Separate from event handling we don’t
> have a way to ROUTE to and from any script in the X3DOM. May I
> suggest this is a W3C or ECMA issue and not a Web3d one? Should we
> raise ROUTEs as a W3C issue? Certainly framework are trying to handle
> ROUTEs in various ways (angular).
DOM does not work on routes, it works on events. Routes are a defined
connection between a source and a destination node. An event is
something that zero or more destination nodes can listen for. Code can
create listeners without the assistance of the source. A route requires
the assistance of the source.
An event-based system can easily underlay a route-based system. The
method that creates the route creates a listener and performs filtering
on the incoming event to ensure that it matches the route
characteristics (correct type, correct node, correct field, etc.), then
consumes the event so it does not get propagated.
Underlying an event-system with a route-based one takes a lot more work.
Route data needs to be sent to something that creates an event. The
target needs to be wrapped with something that listens for that event.
Each route creates a dispatcher and a listener. Since routes are from
destination to target, then it is probably better that the event created
by each route be unique. That way individual routes can be created or
destroyed as needed.
Since a route-based system can be implemented on top of an event-based
system AND the API for HTML documents is DOM with an event-based system,
I do not see how or why this would be a W3C issue. It certainly is not
an ECMA issue because ECMA is concerned with the language design, not
the DOM and HTML events.
>
> It would seem like we are trying to confound a domain specific issue
> with a generic web issue.
>
> I for one would like to ROUTEs between CSS selectors. This would be
> more generic. This is a valuable feature we would like to see in all
> web browsers, not just ones with 3d graphics.
CSS is like a container. You can put things in there and manipulate
them, but the manipulation is done with JavaScript. CSS provides the
styles that are applied to the document elements. When those elements
change state different styles may be applied. Since it takes a
JavaScript action to change a CSS attribute or selector, the "ROUTE"
would just be the next statement that changes a different
attribute/selector.
Leonard Daly
>
> John
>
> On Mon, Mar 4, 2019 at 1:27 AM John Carlson <yottzumm at gmail.com
> <mailto:yottzumm at gmail.com>> wrote:
>
> Do we measure how well we brought Scripting into embedded X3D
> Scripts in x3dv4 by handling fields or ignoring fields or coming
> up with a new syntax?
>
> If we can be honest and say we are supporting fields or not
> supporting fields from the get go, that will help us narrow our
> effort. Let’s do the requirements before the design by all means.
>
> Is ROUTEing to and from HTML Scripts a requirement?
>
> Is ROUTEing to and from X3D Scripts a requirement?
>
> Is ROUTEing from HTML Scripts to X3D Scripts a requirement?
>
> Is ROUTEing from X3D Scripts to HTML Scripts a requirement?
>
> Is ROUTEing a requirement?
>
> Is event handling a requirement? In script? In XML?
>
> Once we have agreed on the requirements, we can proceed with the
> design (double loop architecture).
>
> On Mon, Mar 4, 2019 at 12:51 AM John Carlson <yottzumm at gmail.com
> <mailto:yottzumm at gmail.com>> wrote:
>
> Don, I am not interested in chasing loops around. I put a
> full effort into creating a scenegraph to JavaScript
> connection for X3DOM. It’s time to go somewhere else to look
> at the alternatives. I highly suggest looking at X_ITE’s
> code and other working code. My code seems to be
> fundamentally incomplete (does not handle namespaces properly
> for one).
>
> It starts to get really complex when you use a node as a
> field. A field is not just a signpost
>
> If someone wants to tell me X3D scripting is done for X3DOM, I
> will go look at it. I see absolutely no evidence that fields
> are handled for Scripts.
>
> I am not focused on X3Dv4 and have other tasks.
>
> I do not want to battle over email. I am just trying the best
> I can to report the effort I made.
>
> John
>
> On Sun, Mar 3, 2019 at 4:33 PM Brutzman, Donald (Don) (CIV)
> <brutzman at nps.edu <mailto:brutzman at nps.edu>> wrote:
>
> Thanks for your helpful analysis John. Here are some
> reactions.
>
> Expectation: field definitions for Script and
> ProtoInstance merely define logical connections where
> events are sent + received. Of course a particular DOM
> node labeled "field" with name/type/accessType/value
> attributes is not the final destination we are interested
> in connecting - that particular DOM node is simply a
> signpost label, pointing towards author code living
> elsewhere inside the actual X3D player.
>
> Basics: the X3D scene is integral within the X3D browser,
> and the HTML scripts are external in the HTML page within
> the HTML browser. Each is a separate set of content,
> handled by a pair of browsers running in separate blocks
> of code.
>
> We are figuring out the best way for an author to define
> connections for those events that are expected to pass
> back and forth between HTML page and X3D scene.
>
> The DOM representation of X3D scene content is just that -
> a representation - and any X3D player needs to listen and
> relay events in either direction.
>
> Remember that an "event" is simply a timestamp + value,
> getting passed from source to destination.
>
> There may be several ways for browsers to implement such
> event passing between HTML and X3D content using
> JavaScript. Varieties of implementation are fine since
> the X3D Specifications do not legislate how the code must
> be written - rather the X3Dv4 specification will simply
> define syntax and semantics for such event passing.
>
> Thinking even more simply: of course the same activity
> must happen for all the other X3D nodes that produce or
> consume events. The functionality for other nodes is
> already defined in the specification already, so that is
> considered straightforward in comparison.
>
> Why not start easy and gradually step up the
> sophistication, rather than first "diving into the deep
> end of the pool" with Script and ProtoInstance.
>
> Suggest we focus first on easiest aspects:
> a. defining HTML/X3D syntax for how simple string events
> can get passed between X3D scene and HTML page.
> b. defining HTML/X3D syntax for how numeric/typed events
> can similarly get passed.
> c. Look at X3DOM and X_ITE respectively and see how they
> do it currently.
> d. Get through basic event-passing first before tackling
> variations for author-defined Script and Proto fields (the
> extensible X in X3D).
>
> Wondering what our simplest possible [HTML page + X3D
> scene] example might be to show simple string event passing?
>
> v/r Don
>
>
> On 3/2/2019 1:57 PM, John Carlson wrote:
> > Yeah, I was relaxing most of the day yesterday. I may
> have posted incorrect information. But I still believe
> x3dom fields are not handled at all for scripts, based on
> prior research, and up-to-date investigation in the chrome
> browser (fields and related attributes are black for
> scripts). . They are handled for ComposedShader, and we
> might use that as an example for handling Script fields.
> >
> > Good luck, it’s up to someone else besides me. It
> should be fairly simple to activate script fields I hope.
> I am not sure you want them in HTML scripts anyway.
> >
> > John
> >
> > Sent from Mail
> <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
> >
> > *From: *Brutzman, Donald (Don) (CIV)
> <mailto:brutzman at nps.edu <mailto:brutzman at nps.edu>>
> > *Sent: *Friday, March 1, 2019 6:11 PM
> > *To: *John Carlson <mailto:yottzumm at gmail.com
> <mailto:yottzumm at gmail.com>>
> > *Cc: *X3D Graphics Working Group <mailto:x3d at web3d.org
> <mailto:x3d at web3d.org>>; X3D Graphics public mailing list
> <mailto:x3d-public at web3d.org <mailto:x3d-public at web3d.org>>
> > *Subject: *Re: [x3d] X3D meeting minutes 22 FEB 2019:
> X3D v4 Development statuscategories
> >
> > Thanks for these observations John.
> >
> > I think this points us at the importance of syntax for
> sending events to destinations, either (X3D -> HTML) or
> (HTML -> X3D).
> >
> > There are several links in today's minutes of relevance:
> event descriptions and diagrams for both X3D and HTML.
> >
> > The X3Dv4 spec defines functionality - this will tell
> authors how to construct what they need, and tell
> implementers what syntax/semantics to support. In other
> words, interoperable content. It does not mandate how an
> implementation gets coded.
> >
> > Building examples and comparing X3DOM and X_ITE together
> should get us on path to convergence.
> >
> > It would be good to get Roy Walmsley's original
> HTML+SVG+X3D+Javascript demo of "bouncing ball" back on
> center stage and refreshed. Anyone know where it is?
> Valuable role here for someone...
> >
> > On 3/1/2019 2:19 PM, John Carlson wrote:
> >
> > > In other words, to prevent script source code from
> appearing on the rendered page, I had to remove the text
> or CDATA node. I am fairly sure I removed the field nodes
> as well for X3DOM in X3DJSONLD, favoring my own
> implementation.
> >
> > > I believe that text nodes are incompatible with
> execution, but it might be worth seeing how something like
> jsfiddle does it, if they keep a shadow script or what.
> >
> > > I believe you can keep the fields in DOM (I didn’t)
> if you have an X3DOM implementation of them.
> >
> > > On Fri, Mar 1, 2019 at 4:03 PM John Carlson
> <yottzumm at gmail.com <mailto:yottzumm at gmail.com>
> <mailto:yottzumm at gmail.com <mailto:yottzumm at gmail.com>>>
> wrote:
> > > In other words, scripts (really script fields) do
> not appear in DOM and do not receive or generate DOM events.
> >
> > > John
> >
> > > On Fri, Mar 1, 2019 at 3:46 PM John Carlson
> <yottzumm at gmail.com <mailto:yottzumm at gmail.com>
> <mailto:yottzumm at gmail.com <mailto:yottzumm at gmail.com>>>
> wrote:
> >
> > > As far as I know there is no Script “class”
> or source file in X3DOM, thus no place to hang fields,
> thus nowhere to hook up routes. I did write one at one
> time, it didn’t seem that difficult, but I’m not presently
> on board to rewrite it. I suggest looking at other
> implementations of fields.
> >
> > [...]
> all the best, Don
> --
> Don Brutzman Naval Postgraduate School, Code USW/Br
> brutzman at nps.edu <mailto:brutzman at nps.edu>
> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA
> +1.831.656.2149
> X3D graphics, virtual worlds, navy robotics
> http://faculty.nps.edu/brutzman
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
--
*Leonard Daly*
3D Systems & Cloud Consultant
LA ACM SIGGRAPH Past Chair
President, Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20190304/1af6c05e/attachment-0001.html>
More information about the x3d-public
mailing list