[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