[x3d-public] containerField modifications by script

[Yves Piguet]

I'd rather consider the containerField as just a convenience of the XML encoding. The node with a containerField value is a child of its parent which perhaps you might want to detach and reattach explicitly; not the opposite where the containerField value would be some kind of a child property of the node. I wouldn't keep a containerField property once the X3D scene tree is built. So I agree with you to not support containerField mutation.

Yves

On 26 oct. 2016, at 17:20, Andreas Plesch wrote:

> There may be rare circumstances when an application may want to modify the containerField value of an existing x3d node although I am not sure if this is ever a concern.
> 
> So for cobweb_dom, I do think mutations to the containerField attribute may only need to lead to a warning that such is not supported and ignored.
> 
> Unless there is some situation where this would be valuable ? An application can always delete the x3d node (causing a set_ event to defaults) and then add a new x3d node in place (causing a set_ event to the new value).
> 
> -Andreas
> -- 
> 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