OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmo-webcgm message

[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]