[ http://nagoya.apache.org/jira/browse/XERCESC-1299?page=history ]
Michael Williams updated XERCESC-1299:
--------------------------------------
Attachment: xerces2.50Changes.zip
The zip zip file with the proper directory structure containing only the new
files and files that have changed.
> DOMNode - getChildNodes - wrote efficient list implementation
> -------------------------------------------------------------
>
> Key: XERCESC-1299
> URL: http://nagoya.apache.org/jira/browse/XERCESC-1299
> Project: Xerces-C++
> Type: Improvement
> Components: DOM
> Versions: 2.5.0
> Environment: VC7, Windows XP
> Reporter: Michael Williams
> Attachments: xerces2.50Changes.zip, xerces2.50Changes.zip
>
> Problem:
>
> The DOMNode in xerces has a method called getChildNodes, which returns a
> DOMNodeList of child elements. This DOMNodeList basically provides a thin
> wrapper for the internal linked list, and is not efficient when doing element
> traversals, and direct array-type lookups with the DOMNodeList.item call.
>
> Solution:
>
> The solution to this lies in creating a proper implementation of the xerces
> DomNodeList class. We will extend this class to implement the following
> method
>
> virtual DOMNode *itemByTagNameNS(XMLSize_t index, const XMLCh *namespaceURI,
> const XMLCh *localName) const {return 0;};
> Retrieve an item in a specific collection by index, tag name, and namespace
>
> virtual XMLSize_t getLengthByTagNameNS(const XMLCh *namespaceURI, const XMLCh
> *localName) const {return 0;};
> Get the length of a specific collection by index, tag name, and namespace
>
> virtual bool insertElementAtByTagNameNS(DOMNode *, XMLSize_t index);
> Insert an item into the list by index of the collection of elements with
> matching namespace URI and localname. Returns false if the index < 0 or
> greater than the number of elements of the appropriate type (namespace and
> element name match).
>
> virtual DOMNode *removeElementAtByTagNameNS(XMLSize_t index, const XMLCh
> *namespaceURI, const XMLCh *localName)
> Remove an element by index of the collection of elements with matching
> Namespace URI and localname. Returns the removed node upon success, or false
> if the index < 0 or greater than the number of elements of the appropriate
> type.
>
> virtual bool insertElementAt(DOMNode *, XMLSize_t index) = 0;
> Inserts an element into the list of child elements by index. Returns false
> if the index < 0 or greater than the number of child elements.
>
> virtual DOMNode *removeElementAt(XMLSize_t index) = 0;
> Remove an element by index of the collection of elements with matching
> Namespace URI and localname. Returns the removed node upon success, or false
> if the index < 0 or greater than the number of child elements.
>
> Comments regarding element navigation:
>
> All methods of navigating elements will probably yield about the same level
> of performance, and linked list navigation or array navigation can be mixed
> without any adverse performance effects.
>
> Comments regarding element deletion and insertion:
>
> Choose one of the following three methods for deleting and inserting children
> elements into an element, and for the same element, do not mix the methods.
> Otherwise performance will most likely suffer.
>
> 1. Inserting and deleting by linked list methods (original xerces methods)
> 2. Inserting and deleting into the vector of ALL children (not using
> namespace and nodename identifiers)
> 3. Inserting and deleting by NS and nodename.
>
> The reason is that because algorithms to insert or delete from a linked list
> can be very efficient, but then to try to find the element to be deleted in
> an array will yield slow performance, because there is no good way to know
> the array index of the element beforehand.
>
> Also, the algorithms to partition an elements children into a general child
> array, and arrays by namespace and element name, will not yield good
> performance if these two sets of arrays (partitioned and general) are both
> used in the same element for inserting and deleting elements.
>
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
