[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: WebCGMNodeList
Hi guys, I'm unclear about something... that is, how are users going to use WebCGMNodeList!? We have the following methods which return WebCGMNodeList: WebCGMNodeList WebCGMNode.childNodes; WebCGMNodeList WebCGMNode.attributes; WebCGMNodeList WebCGMNode.getElementsByTagNameNS() WebCGMNodeList WebCGMPicture.getAppsStructureByName() WebCGMNodeList WebCGMPicture.createWebCGMNodeList() And the following which requires one as input: WebCGMPicture.hightlight(in WebCGMNodeList) The WebCGMNodeList interface is as follows: interface WebCGMNodeList { readonly attribute unsigned long count; WebCGMNode item(in unsigned long index); WebCGMNode removeItem ( in unsigned long index ) raises( WebCGMException ); WebCGMNode appendItem ( in WebCGMNode newItem ) raises( WebCGMException ); void clear() raises( WebCGMException ); }; My concerns are related to a node list of APS nodes and a node list of Attr nodes. It is pretty clear that 'count' and 'item' have value; they are required to walk through a list of nodes regardless if they are APS or Attr. In a previous email, I said that there are technical reasons why 'clear' shouldn't be present. So that leaves 'removeItem' and 'appendItem' as questionable... Let's start with 'appendItem', it is needed for adding WebCGMNodes to a list of objects to be highlighted. But what happens if someone does: WebCGMNode.childNodes.appendItem() // this adds a new child I thought we wanted to forbid the 'addition' and 'deletion' of APS in the DOM. If that is true, I don't see a use case for 'removeItem', except maybe to remove an item from a node list which shouldn't be highlighted. 'removeItem' and 'appendItem' on Attr node list also have some issues. 'removeItem' could be seen as an equivalent to removeAppStructureAttr, and 'appendItem' as setAppStructureAttrList. The problem is that we don't have a createAttrNode method to feed into appendItem. Should we add such a method? I'm not sure if people are following me, I may not be very clear. But here's my proposal. Proposal: All methods returning a WebCGMNodeList, with the exception of createWebCGMNodeList, must return 'readonly' node lists. With this approach 'appendItem' and 'removeItem' can remain on the interface and will only work for node lists aimed at being used with the highlight() method. Thoughts? -- Benoit mailto:benoit@itedo.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]