[x3d-public] DOM integration with cobweb

Joe D Williams joedwil at earthlink.net
Thu Sep 15 20:16:15 PDT 2016


We need to look at issues between abstract SAI and ECMAscript SAI.

//try out x3d events on touchsensor
ts = document.querySelector('TouchSensor');
coords = document.querySelector('#coords');
hitpt = document.querySelector('#hitpoint');
ts.addEventListener('isOver', function(evt) {
 if (evt.value) {
  coords.textContent = " " + evt.fields.hitPoint_changed;
  //alert('isOver event:'+evt.value+'\nHitPoint: 
'+evt.fields.hitPoint_changed)
 }
 });
ts.addEventListener('hitPoint_changed', function(evt) {
 if (evt.value) {
  hitpt.textContent = " " + evt.value;
  //alert('isOver event:'+evt.value+'\nHitPoint: 
'+evt.fields.hitPoint_changed)
 }
 });

I think no way to do this without TouchSensor interfaces.
Seems more responsive than I expected. Modern browser scripting is 
much improved.

Fine example, Thanks

All Best,,
JOe

----- Original Message ----- 
From: "Andreas Plesch" <andreasplesch at gmail.com>
To: "Joe D Williams" <joedwil at earthlink.net>
Cc: "X3D Graphics public mailing list" <x3d-public at web3d.org>; "John 
Carlson" <yottzumm at gmail.com>
Sent: Thursday, September 15, 2016 7:16 AM
Subject: Re: [x3d-public] DOM integration with cobweb


> Ok, I thought about relaying x3d sensor events to html DOM events a 
> bit
> more and settled (for now) on requiring a x3d sensor (eg. 
> TouchSensor).
>
> First, it turned out it was not necessary to modify cobweb in order 
> to come
> up with a first demonstrator implementation of a x3d event to DOM 
> event
> relay:
>
> https://andreasplesch.github.io/cobweb_dom/index.xhtml
>
> In the HTML each such sensor element would then be able to have 
> listeners
> to DOM events with names corresponding the field names such as
> 'hitPoint_changed' or 'isOver'. So a web page programmer can then 
> use
> sensorElement.addEventListener('hitPoint_changed',
> myhandlerfunction(event)) .The shortcut attributes 
> onhitPoint_changed and
> such may be expected to be available as well but it would clutter 
> the x3d
> xml and invalidate it. It is also not really necessary.
>
> In addition, it should be possible to also provide events with more
> familiar names such as 'click' as aliases for the field events.
>
> After carefully reading through the javascript SAI spec. I found the
> field.addFieldCallback() SAI function here:
>
> http://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#t-FieldFunctions
>
> It does not seem to have a corresponding service in the SAI spec.:
>
> http://www.web3d.org/documents/specifications/19775-2/V3.3/Part02/servRef.html#FieldServices
> ?
>
> But I was glad to see that the addFieldCallback() function is 
> implemented
> in cobweb (although a little different from what the terse spec. 
> suggests)
> and is a great way to hook into the field events. This is really 
> what my
> relay is based on.
>
> The current implementation is restricted to TouchSensor but should 
> cover
> all of its field events. For the event object which is passed to the 
> DOM
> handler function, I added a .value property which has the value of 
> the
> field, but also a .fields property which is an object containing all 
> of the
> nodes fields for easy access. See example, and implementation in
> cobweb_dom.js
>
> It should be possible to generalize that to all sensor nodes, in 
> fact the
> code is designed that way. Perhaps it makes sense to attach these 
> field
> callbacks to all fields on all nodes, not just sensor nodes ?  To be 
> able
> to pick up on interpolator events, for example ? It feels like this 
> could
> affect performance since a lot of DOM events may be dispatched ? 
> Well, it
> would come down to trying it.
>
> Any feedback or questions welcome,
>
> Andreas
>
>
> On Wed, Sep 14, 2016 at 6:34 PM, Joe D Williams 
> <joedwil at earthlink.net>
> wrote:
>
>> What I have in mind is to require x3d sensor nodes, unlike x3dom 
>> which
>>>
>> dispatches events on any shape.
>>
>> Fine, I would like to see that construction rather than the onclick 
>> and
>> html script.
>> All Best,
>> Joe
>>
>> ----- Original Message ----- From: "Andreas Plesch" <
>> andreasplesch at gmail.com>
>> To: "X3D Graphics public mailing list" <x3d-public at web3d.org>
>> Sent: Wednesday, September 14, 2016 12:58 PM
>> Subject: Re: [x3d-public] DOM integration with cobweb
>>
>>
>> Hello,
>>>
>>> thanks to a transcontinental flight I made some progress on my 
>>> bridge
>>> between the cobweb x3d scene graph and the DOM tree with x3d 
>>> elements.
>>>
>>> Here are two simple examples:
>>>
>>> https://andreasplesch.github.io/cobweb_dom/addremoveNode.xhtml
>>>
>>> This is the x3dom add/remove nodes example (
>>> http://examples.x3dom.org/example/x3dom_addRemoveNode.html) with 
>>> minor
>>> adjustments for xhtml but unchanged javascript control code.
>>>
>>> https://andreasplesch.github.io/cobweb_dom/index.xhtml
>>>
>>> This demonstrates both how html attribute changes are picked up by 
>>> the x3d
>>> scene graph, and how adding and removing html elements also is 
>>> reflected
>>> in
>>> the x3d scene graph. The box trafos are root nodes, and the 
>>> removable
>>> Material node is a field of the Shape node.
>>>
>>> I put the bridge code in a separate file, so it can now be easily 
>>> added to
>>> any page.
>>>
>>> The next step would be to translate x3d sensor events into 
>>> appropriate DOM
>>> events. This will require probably more modification of the cobweb 
>>> code
>>> itself and a clear strategy.
>>>
>>> What I have in mind is to require x3d sensor nodes, unlike x3dom 
>>> which
>>> dispatches events on any shape.
>>>
>>> -Andreas
>>>
>>>
>>>
>>>
>>> On Mon, Sep 5, 2016 at 6:09 PM, Andreas Plesch 
>>> <andreasplesch at gmail.com>
>>> wrote:
>>>
>>> I could generalize the handling of attribute changes by using the 
>>> cobweb
>>>> parser, with only a few lines (but a lot of investigation). This 
>>>> means
>>>> that
>>>> most field types should be accessible from the DOM now. However, 
>>>> I only
>>>> tested with diffuseColor. I also figured out how to immediately 
>>>> apply the
>>>> changes by triggering a set event for the changed field.
>>>>
>>>> Adding and removing of nodes is next. I think statements also 
>>>> need
>>>> special
>>>> treatment. For external statement changes and prototype changes, 
>>>> it may
>>>> be
>>>> best to reload the whole scene (?) .
>>>>
>>>> I adopted the x3dom basic attribute manipulation example:
>>>>
>>>> https://andreasplesch.github.io/cobweb_dom/jqueryui_cobweb.xhtml
>>>>
>>>> It worked without changes to the control code and demonstrates 
>>>> that the
>>>> mutation observer is fast. This means it may be time to provide 
>>>> this as a
>>>> simple js library to add on to cobweb pages since there is enough
>>>> functionality.
>>>>
>>>> -Andreas
>>>>
>>>>
>>>>
>>>> On Sun, Sep 4, 2016 at 12:40 AM, Andreas Plesch 
>>>> <andreasplesch at gmail.com
>>>> >
>>>> wrote:
>>>>
>>>> Here is a thought experiment which developed into a strawman
>>>>> implementation.
>>>>>
>>>>> First the result:
>>>>>
>>>>> https://andreasplesch.github.io/cobweb_dom/index.xhtml
>>>>>
>>>>> After clicking the new color button, and moving the mouse, the 
>>>>> color of
>>>>> the box should change.
>>>>>
>>>>> The interesting feature here is that the color change is 
>>>>> triggered by a
>>>>> modification of the diffuseColor _attribute_ of the Material 
>>>>> _html_
>>>>> element, in a way that should be possible to generalize to most 
>>>>> (all)
>>>>> fields in x3d nodes.
>>>>>
>>>>> This is the x3dom pattern of controlling a x3d scene. But here I 
>>>>> use
>>>>> cobweb as the x3d browser. Cobweb has very good coverage of the 
>>>>> x3d
>>>>> standard including Prototypes, scripting and the SAI. Being able 
>>>>> to use
>>>>> both, internal x3d scripting and external control using the DOM 
>>>>> could be
>>>>> quite fruitful.
>>>>>
>>>>> I had to modify cobweb only slightly based on an idea developed 
>>>>> during
>>>>> the discussion around the id attribute inspired by x3dom. The 
>>>>> main
>>>>> change
>>>>> is to attach a reference to the generated x3d scene graph node 
>>>>> from the
>>>>> DOM
>>>>> element during parsing. This then enables access from the DOM to 
>>>>> the x3d
>>>>> node.
>>>>>
>>>>> The next step would be to expand to all field types, perhaps 
>>>>> reusing the
>>>>> cobweb parser, or SAI functions. and to allow for removal and 
>>>>> addition
>>>>> of
>>>>> nodes.
>>>>>
>>>>> [If all works, there is the issue of <script> being claimed by 
>>>>> the web
>>>>> browser. I think the only solution may be to break backward
>>>>> compatibility
>>>>> and allow <x3dScript> as an alias to <script>]
>>>>>
>>>>> The examples also shows how to use inline x3d rather than an url 
>>>>> with
>>>>> cobweb. Since cobweb is strict about XML, this is only possible 
>>>>> if the
>>>>> html
>>>>> page has xhtml encoding. xhtml in turn triggered an issue with 
>>>>> the fps
>>>>> counter display and the context menu, as a side note.
>>>>>
>>>>> The code is all on github: 
>>>>> https://github.com/andreasplesch/cobweb_dom
>>>>>
>>>>> I had to learn a lot about cobweb (and jquery and AMD...) and 
>>>>> look
>>>>> forward to any feedback or even hands-on contributions ? Perhaps 
>>>>> the
>>>>> cobweb
>>>>> team is also interested ?
>>>>>
>>>>> -Andreas
>>>>>
>>>>> --
>>>>> Andreas Plesch
>>>>> 39 Barbara Rd.
>>>>> Waltham, MA 02453
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Andreas Plesch
>>>> 39 Barbara Rd.
>>>> Waltham, MA 02453
>>>>
>>>>
>>>
>>>
>>> --
>>> 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
>>>
>>>
>>
>
>
> -- 
> Andreas Plesch
> 39 Barbara Rd.
> Waltham, MA 02453
> 




More information about the x3d-public mailing list