[x3d-public] DOM integration with cobweb

[Joe D Williams]

> 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
>