[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cgmo-webcgm] DOM node are 'live'
And I found a typo in the WebCGMNodeList IDL definition: WebCGMNode appendItem ( in WebCGMString newItem ) raises( WebCGMException ); should be: WebCGMNode appendItem ( in WebCGMNode newItem ) raises( WebCGMException ); The wording in the spec is ok though... Action item on me or Lofton, I don't care... -- Benoit mailto:benoit@itedo.com Thursday, February 10, 2005, 9:19:31 AM, Benoit wrote: BB> Hi, BB> I'm not sure if other implementers dealt with this issue already, BB> but we recently did, and the spec should really be clarified. The BB> issue has to do with the nodes being 'live' or not. The DOM level 3 BB> specification clearly specifies that DOM nodes are live: BB> "The DOM also specifies a NodeList interface to handle ordered lists BB> of Nodes, such as the children of a Node, or the elements returned BB> by the Element.getElementsByTagNameNS(namespaceURI, localName) BB> method, and also a NamedNodeMap interface to handle unordered sets BB> of nodes referenced by their name attribute, such as the attributes BB> of an Element. NodeList and NamedNodeMap objects in the DOM are BB> live; that is, changes to the underlying document structure are BB> reflected in all relevant NodeList and NamedNodeMap objects. For BB> example, if a DOM user gets a NodeList object containing the BB> children of an Element, then subsequently adds more children to that BB> element (or removes children, or modifies them), those changes are BB> automatically reflected in the NodeList, without further action on BB> the user's part. Likewise, changes to a Node in the tree are BB> reflected in all references to that Node in NodeList and BB> NamedNodeMap objects." BB> The wording in our specification is not that clear, but I think it BB> should be. BB> On a related matter... I earlier proposed that WebCGMStringList be BB> added a clear() method and that WebCGMNodeList have the same. Based BB> on implementation feedback, I made a mistake. Sorry. It is fine for BB> WebCGMStringList to have a clear() method, but not for BB> WebCGMNodeList. Instead, the removeItem method should be used to BB> clear a node list. Here's why: BB> var aps = cgmPic.getAppStructureById("_1"); // returns an APS BB> var a = aps1.attributes; // returns a node list BB> var i = a.item(0); // return a attr node BB> a.clear(); // a is empty and aps1 doesn't have any attributes BB> // what's the state of i? BB> The method removeItem returns the deleted node, so it is still BB> accessible: WebCGMNode removeItem ( in unsigned long index ). The BB> same is not applicable for clear(). BB> WebCGMStringLists do not contain interface pointers and are BB> therefore not live, the problem is not existent in this case. BB> Thoughts? BB> I'm willing to take one action item: BB> 1) To propose wording with regards to DOM nodes being live. BB> Could Lofton take one: BB> 2) To remove the clear() method on WebCGMNodeList.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]