[x3d-public] getContainerField() [was cobweb DOM integration]

Mon Oct 10 07:27:34 PDT 2016

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20161010/844addfb/attachment-0001.html>