[x3d-public] DOM integration with cobweb (Holger Seelig)

Tue Sep 20 16:28:27 PDT 2016

Hi Don, Holger, list,

I worked more on exposing x3d events to the web page DOM, so that DOM event
listeners can pick up those events and take action.

Here is an updated example:

https://andreasplesch.github.io/cobweb_dom/perf.xhtml

Some design changes were necessary. First, while I had used the Event()
constructor to generate the DOM event to be dispatched, it seems more
appropriate to use the CustomEvent() constructor which comes with a
recognized mechanism to provide an event related value.

https://developer.mozilla.org/en-US/docs/Web/API/CustomEvent/CustomEvent

As a consequence, the DOM event handler has to use a evt.detail property
object to access delivered values, eg.evt.detail.value (instead of
evt.value).

Second, the UI Event working draft suggests to use a prefix for new DOM
event type names

https://www.w3.org/TR/DOM-Level-3-Events/#extending-events

I used 'x3d' as prefix in the example.

Third, I think it is necessary that the generated event type uniquely
identifies the generating node and field name. Otherwise, event listeners
have to reconstruct the source and check if it is the kind of event they
expect to listen to.

In the example and bridge code I construct the event type as a
concatenation of 'x3d', source node type, source node x3d name (DEF) and
field name which leads to long, unwieldy event names. Perhaps x3d+DEF+field
suffices.

Any feedback or ideas welcome,

Andreas

On Mon, Sep 19, 2016 at 7:33 PM, Don Brutzman <brutzman at nps.edu> wrote:

> Thanks for these thoughtful efforts.  In many ways, doing DOM well is the
> essence of how X3D might integrate deeply with HTML5 and the Open Web
> Platform (OWP).  Experimenting, testing, comparing, improving etc. is of
> course expected.  Event exchange between systems is where the "rubber hits
> the road" and also where implementation innovation will continue in future
> browsers.
>
> When we align specifications for content stability, it becomes hard to go
> too far wrong...  we are designing for the long term.
>
> *Having 2 open-source implementations in X3DOM and Cobweb is really
> powerful.*  Lots of opportunity here!  Looking forward to further progress
> together, for everyone's benefit.
>
> v/r Don
>
>
> On 9/17/2016 11:01 AM, Andreas Plesch wrote:
>
>> Hi Holger,
>>
>> I am open to integrating the DOM code with the official cobweb release.
>> For now it may make most sense to keep it in a separate file so it remains
>> optional. Let's discuss further details off-list.
>>
>> If you have ideas or just thoughts how or if the standard should reflect
>> and specify such a X3D-web page DOM integration, please do not hesitate to
>> mention them here in on the list. Any input would be greatly appreciated by
>> all, I am sure.
>>
>> -Andreas
>>
>>     Message: 1
>>     Date: Fri, 16 Sep 2016 22:41:24 +0200
>>     From: Holger Seelig <holger.seelig at yahoo.de <mailto:
>> holger.seelig at yahoo.de>>
>>     To: x3d-public at web3d.org <mailto:x3d-public at web3d.org>
>>     Subject: Re: [x3d-public] DOM integration with cobweb
>>     Message-ID: <dcdf2e55-defb-79b5-8437-ebecb15fc5eb at yahoo.de <mailto:
>> dcdf2e55-defb-79b5-8437-ebecb15fc5eb at yahoo.de>>
>>     Content-Type: text/plain; charset=UTF-8; format=flowed
>>
>>     Would like to include your fantastic work in the next official
>> release,
>>     with some documentation added.
>>
>>     Cheers,
>>     Holger
>>
>>
>>     Am 16.09.2016 um 21:54 schrieb Andreas Plesch:
>>     > Holger was kind enough to amend cobweb in its latest release to
>> allow
>>     > convenient access to its x3d nodes from a custom property added to
>> DOM
>>     > nodes within the x3d scene. This means that the (experimental) dom
>>     > bridge code now works with the regular cobweb release.
>>     >
>>     > Since there is enough functionality, I put the code in a release
>> folder
>>     > to make it available from:
>>     >
>>     > https://raw.githubusercontent.com/andreasplesch/cobweb_dom/m
>> aster/release/cobweb_dom.0.1.js <https://raw.githubusercontent
>> .com/andreasplesch/cobweb_dom/master/release/cobweb_dom.0.1.js>
>>     > or
>>     > https://rawgit.com/andreasplesch/cobweb_dom/master/release/
>> cobweb_dom.0.1.js <https://rawgit.com/andreasple
>> sch/cobweb_dom/master/release/cobweb_dom.0.1.js>
>>     >
>>     > Just load it after loading cobweb.[min].js.
>>     > There is a chance the code could work with D3 as a DOM manipulation
>>     > library but I did not test this.
>>     >
>>     > Holger also implemented the .dispose() SAI function and other
>>     > functionality which should make the bridge code much cleaner.
>>     >
>>     > Also, it turns out that my performance issues were not due to the
>> event
>>     > handling but just a very busy PC with its 32GB memory completely
>> filled
>>     > up. But I do suspect that cobweb is more memory demanding and prone
>> to
>>     > more frequent GC stuttering than x3dom is.
>>     >
>>     > -Andreas
>>     >
>>
>>
>> --
>> Andreas Plesch
>> 39 Barbara Rd.
>> Waltham, MA 02453
>>
>>
>> _______________________________________________
>> x3d-public mailing list
>> x3d-public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>
>>
>
> all the best, Don
> --
> Don Brutzman  Naval Postgraduate School, Code USW/Br
> 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/brutzma
> n
>

-- 
Andreas Plesch
39 Barbara Rd.
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160920/a9265502/attachment.html>