[x3d-public] [x3dom-users] inline access from dom
Leonard Daly
web3d at realism.com
Sun Oct 2 09:24:19 PDT 2016
Andreas,
Some background first. Not that you need this, but others following the
discussion might. The X3D Standard
(http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/networking.html#Inline)
indicates that all nodes loaded via an Inline occupy a separate
namescope (sort-of like a name-space, but without a lot of the
structure) from the parent scene. This prevents direct communication
between the parent and the children of an Inline. The Import/Export
statements allow certain information to be passed between the
parent/child. The namescope applies only to information passing.
Rendering is all rolled-up.
X3DOM implements this requirement with the following. If only the
X3D-defined fields are used, then the Inlined nodes are not loaded into
the (HTML) DOM. They are maintained in the list of rendered nodes so
content can be visible. Since they are not in the DOM, those nodes
cannot be accessed with DOM-oriented calls (e.g., jQuery). At this time
X3DOM does not support Import/Export.
If the X3DOM field 'namespacename' is present and a value is provided,
the value appended with a double underscore is prepended to all DEFs. If
the field 'mapdeftoid' is TRUE, then the prepending is also done to IDs
(it's actually a little more complicated than that, but this will do for
now). The Inlined nodes are still maintained in a separate X3-DOM
namescope. This is necessary because Inline's 'url' field can change and
those nodes would need to be removed. The separate namescope allows
those nodes to be identified.
[Switching back to regular HTML] Elements added to an HTML document
through the DOM become full elements in the page's DOM. There is no
separate namescope. It is the responsibility of the adding code to
ensure that there are no 'id' value conflicts (ids are unique throughout
the document).
This is similar to X3D in that DEF names need to be unique throughout
the namescope. This slight variant allows the author to use an Inline
multiple times because each instance is in its own namescope.
A 3D environment in a web page should be able to Inline the same file
multiple times (e.g., a row of trees) without causing a problem with the
DOM. It should also be possible to group and individually animate those
objects. For example, a number of trees of the same kind would all sway
in the wind. Trees of the same height would behave similarly. One tree
might be special and need to sway differently. It should be possible to
apply an animation to the entire class of trees and a special animation
to the special tree. If all of the trees had the same class, then (at
least theoretically) the animation could be applied to the class. The
special tree would have a unique ID so that could be animated separately.
What Andreas has written below is an element-attribute-value selector
that goes down to the final leaf to set a value. If the Inline's parent
(the file that contains the node <Inline url='InlineParent.x3d'>) uses
this node multiple times, then Andreas' querySelector statement would
change all of the arrowheads that fit the criteria. This is not
necessarily bad, but just needs to be considered. Anything not starting
with an ID reference or a unique tag in the scene (e.g., <body>) may not
refer to a unique node.
=== InlineParent.x3d ===
:
<Inline DEF='arrow' url='arrow.x3d'></Inline>
:
=== arrow.x3d ===
:
:
<Appearance>
<Material DEF='arrowheadmat' diffuseColor='0 0 1'></Material>
:
</Appearance>
So I think rather than ask what would it take to adopt the selector
approach, a more fundamental question needs to be answered - how should
files be imported into a scene and inserted into the (HTML) DOM? I think
once that question is answered the rest will be easy.
I created a new public Wiki page on Web3D.org
(http://www.web3d.org/wiki/index.php/Importing_and_adding_nodes_in_HTML)
where results of this discussion are recorded.
Leonard Daly
> Hi Leonard,
>
> I guess I am looking for guidance and a discussion on how ideally
> content internal to Inlines should be identified. I do like the CSS
> selector approach because if does not involve adding an additional
> namespacename field to Inline. But there may be other approaches.
>
> What would it take to adopt the selector approach in x3dom ? So you
> can do this:
>
> SceneElement.querySelector("Inline[DEF='arrow']
> Material[DEF='arrowheadmat']).setAttribute("diffuseColor","1 0 0")
>
> -Andreas
>
> On Sat, Oct 1, 2016 at 11:54 PM, Leonard Daly <web3d at realism.com
> <mailto:web3d at realism.com>> wrote:
>
> Andreas,
>
> I am not sure if you are looking for comments, advice, discussion,
> or just posting a notice. I don't want to go off on a tangent
> here. I am rather familiar with how and almost why X3DOM does it.
>
>
> Leonard Daly
>
>
>> I am working on adding DOM access to inline scenes for my Cobweb
>> DOM bridge:
>>
>> https://andreasplesch.github.io/cobweb_dom/tests/inline_in_inline.xhtml
>> <https://andreasplesch.github.io/cobweb_dom/tests/inline_in_inline.xhtml>
>>
>> The idea is to add the external inline scene DOMs to the main
>> scene DOM as children of the Inline elements. Once added, the
>> mutation observer picks up modifications of these children and
>> does not need to do anything other than it already does for the
>> main scene.
>>
>> It works well although I do not know how web browsers deal with
>> large combined DOMs. Also, a small addition to Cobweb.js is
>> currently needed.
>>
>> One effect is that one can use CSS selectors with querySelector
>> to drill down to specific elements in inline scenes, even through
>> hierarchies of inlined inlines. See example. This way the DEF
>> names can be used even if they are identical across scenes. X3D
>> semantics and functioning is not affected.
>>
>> X3dom uses a different approach of prefixes to id/DEF attributes
>> to enable access to elements in inlines. Not sure if x3dom could
>> use instead or in addition Selectors ? This would require adding
>> the Inline DOMs to the main DOM but perhaps this is already
>> almost done ?
>>
>> So I am considering also adding the same option of a
>> namespacename prefix to element IDs but the effort would be
>> really for compatibility. Thinking about it, while possible
>> probably not a priority unless there is a compelling use case.
>>
>> X3D has EXPORT/IMPORT to deal with accessing nodes in inlines. I
>> think the SAI equivalent is roughly that all nodes are EXPORTed
>> by default and that in addition to a DEF name it becomes possible
>> to address a node by its path in the scene hierarchy. Perhaps
>> something to consider for the standard: X3D selectors.
>>
>> Andreas
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org!http://sdm.link/slashdot
>>
>> _______________________________________________
>> X3dom-users mailing list
>> X3dom-users at lists.sourceforge.net
>> <mailto:X3dom-users at lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/x3dom-users
>> <https://lists.sourceforge.net/lists/listinfo/x3dom-users>
>
> -- *Leonard Daly* 3D Systems Architect & Cloud Consultant
> President, Daly Realism - /Creating the Future/
>
> --
> Andreas Plesch 39 Barbara Rd. Waltham, MA 02453
-- *Leonard Daly* 3D Systems Architect & Cloud Consultant President,
Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20161002/93a768c9/attachment-0001.html>
More information about the x3d-public
mailing list