[x3d-public] getContainerField() [was cobweb DOM integration]
Joe D Williams
joedwil at earthlink.net
Mon Oct 10 10:50:45 PDT 2016
> only a few cases where containField value is other than the default.
>
the language objects are all designed to provide appropriate default
content for fields.
If not specified in user code the default container for a field which
is a node is always available in the schema. If not, then it is a
problem. The problem is seen in Collision where we allow any child to
be proxy rather than first or last and in prototypes where the first
node defines the container for the structure.
Memory lapses for more.but that is basically why X3D XML encoding uses
minimum of 'wrapper' elements,
Thanks and Best,
Joe
----- Original Message -----
From: "Joe D Williams" <joedwil at earthlink.net>
To: "Roy Walmsley" <roy.walmsley at ntlworld.com>; "'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 9:31 AM
Subject: Re: [x3d-public] getContainerField() [was cobweb DOM
integration]
> 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
>>
>
>
> _______________________________________________
> 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