[x3d-public] getContainerField() [was cobweb DOM integration]
Joe D Williams
joedwil at earthlink.net
Mon Oct 10 09:31:04 PDT 2016
RIght, ROy,
containerField is just the way we got rid of what were called wrapper
tags. Ass you siad, the classic encoding include the 'wrapper tags'
built in. But we did not wish to duplicate this Ckassuc stricture in
the XML:
this:
<proxy>
<Group DEF=”group3” />
</proxy>
We did not want to have those pesky wrappers when there are only a few
cases where it is other than the default.
All Best,
Joe
----- Original Message -----
From: "Roy Walmsley" <roy.walmsley at ntlworld.com>
To: "'Andreas Plesch'" <andreasplesch at gmail.com>; "doug sanden"
<highaspirations at hotmail.com>
Cc: "'X3D Graphics public mailing list'" <x3d-public at web3d.org>
Sent: Monday, October 10, 2016 7:27 AM
Subject: Re: [x3d-public] getContainerField() [was cobweb DOM
integration]
Hi all,
Interesting questions raised below. I will try to provide some
answers.
Q1 – Usually (always) just one field for a given parent nodetype. I
don’t have an exhaustive answer, but I will give an example. It may be
the only one, not sure. Look at the Collision node, (19775-1, 23.4.2,
http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/navigation.html#Collision.
Note that there is a children field and a proxy field, both of which
accept X3DChildNode. In other words, what can go in one can also go in
the other.
The Collision node has a containerField attribute with a default value
of “children”. This simply tells us that, unless otherwise specified,
it will go into the children field of its parent node.
Similarly, if we look at, for example, MetadataBoolean, it has a
containerField with the default value of “metadata”. So,
MetadataBoolean, unless otherwise specified, will go into the metadata
field of the parent node.
Q2 – ExternProto: Hm… good question. My first thought was that there’s
nothing there. But, on reflection, it’s not about the definition using
ExternProtoDeclare, or ProtoDeclare. It’s about where you use it. And
that means ProtoInstance. Look there, and you see that there is an
attribute for containerField, with a default value of “children”. So,
if you want the ProtoInstance in some other field, you need to specify
a different value for containerField.
Q3 – containerField: I think of the parent node as the “container”,
and the “field” is the field that does the containing. And you are
right, it is not a field. It is an XML attribute. It is not required,
for example, in the classic VRML encoding, or the JSON encoding,
because the encoding is such that, for each node, fields have their
names explicitly written, followed by their values. So, for Collision,
we would write:
Collision {
children [
DEF group1 Group{},
DEF group2 Group{}
],
proxy [
DEF group3 Group {}
]
}
But, when it comes to XML, if we write
<Collision>
<Group DEF=”group1”/>
<Group DEF=”group2”/>
<Group DEF=”group3”/>
</Collision>
Then all three Group nodes would be loaded into the children field of
the Collision node, because the default value of the containerField
attribute for Group is “children”. So, to reproduce the VRML encoding
we write:
<Collision>
<Group DEF=”group1”/>
<Group DEF=”group2”/>
<Group DEF=”group3” containerField=”proxy”/>
</Collision>
The only way to definitively know which is the default containerField
for any node type is to read it from the schema or DTD.
Hope these comments help,
Regards,
Roy
From: x3d-public [mailto:x3d-public-bounces at web3d.org] On Behalf Of
Andreas Plesch
Sent: 10 October 2016 14:28
To: X3D Graphics public mailing list <x3d-public at web3d.org>
Subject: Re: [x3d-public] getContainerField() [was cobweb DOM
integration]
Hi Doug,
good questions.
Date: Mon, 10 Oct 2016 12:53:22 +0000
From: doug sanden <highaspirations at hotmail.com
<mailto:highaspirations at hotmail.com> >
To: X3D Graphics public mailing list <x3d-public at web3d.org
<mailto:x3d-public at web3d.org> >
Subject: Re: [x3d-public] cobweb DOM integration
if added to SAI SFNode interface, then it might need a parameter:
sfnode.getContainerField(parent) since some nodetypes have multiple
containerfield targets by fieldname, but usually (Q1. always?) just
one field for a given parent nodetype.
I had the same suspicion and you confirmed that there are nodetypes
which have multiple containerfield targets. It may be useful to put
together a list of these starting with some examples. Do any come to
mind ? I believe cobweb does not accept a parent parameter to the
.getContainerField() method, but I may be wrong.
I seem to remember that there are cases where it is necessary to
provide an explicit containerField attribute. Not sure what these are,
but the fact that there is a containerField attribute indicates that
it is sometimes required.
Q2. in an ExternProto scenario, before extern proto is loaded, and no
concrete node as first node of protobody, how to determine via a
function what is the containerfield its instances should target their
parents? Can we put a field 'containerField' or MFString
containerFields? Does cobeweb delay instancing extern protos until the
extern is loaded and concretized before allowing getContainerField?
I did not explore ExternProtos in cobweb sofar, so I do not have
answers, But I also suspect that a containerField field can be used.
Not sure when instancing occurs but I would also expect after
completion of the async, loading of the externproto.
Q3. terminology: does 'container' part of containerfield refer to the
parent ie parent is container or does it refer to the field ie a field
is a container?
I thought 'container' refers to the parent node and 'field' refers to
field of the parent. So one would say the 'containerfield field'. But
I am not sure if containerfield is a field or just a xml attribute
which acts as a helper.
-Andreas
________________________________________
From: x3d-public <x3d-public-bounces at web3d.org
<mailto:x3d-public-bounces at web3d.org> > on behalf of Andreas Plesch
<andreasplesch at gmail.com <mailto:andreasplesch at gmail.com> >
Sent: October 9, 2016 9:00 PM
To: X3D Graphics public mailing list
Subject: Re: [x3d-public] cobweb DOM integration
On Sun, Oct 9, 2016 at 10:35 PM, Andreas Plesch
<andreasplesch at gmail.com <mailto:andreasplesch at gmail.com>
<mailto:andreasplesch at gmail.com <mailto:andreasplesch at gmail.com> >>
wrote:
...
What are other strategies for determining the field in a container
node which should (most likely) be set given just the identity of a
new node and its containing (parent) node ?
Some more investigating brought to light that cobweb.js already has a
node.getContainerField() method which seems to be exactly what I was
looking for. Excellent.
The SAI does not have such a function:
http://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#t-SFNodeFunctions
Should it be added to the spec. ?
--
Andreas Plesch
39 Barbara Rd.
Waltham, MA 02453
--
Andreas Plesch
39 Barbara Rd.
Waltham, MA 02453
------------------------------
Subject: Digest Footer
_______________________________________________
x3d-public mailing list
x3d-public at web3d.org <mailto:x3d-public at web3d.org>
http://web3d.org/mailman/listinfo/x3d-public_web3d.org
------------------------------
End of x3d-public Digest, Vol 91, Issue 16
******************************************
--
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
>
More information about the x3d-public
mailing list