Re: DOM_ IDOM_ Integration

[Lenny Hoffman]

Hi Tinny,   Within Buxzilla I could not see where to add an attachement.  So I tried three separate messages to the list and they all got rejected for being too large, even though they were less then 100,000 bytes, which is the limit indicated in the failure notice.  Am I missing something? Do you have any other suggestions?   Thanks,   Lenny ----- Original Message ----- From: Tinny Ng To: [EMAIL PROTECTED] Sent: Tuesday, January 22, 2002 9:14 AM Subject: Re: DOM_ IDOM_ Integration Lenny, I think Bugzilla will only forward the attachment link to the mailing list, not the actual attachment.  But if it is really large, it's not a bad idea to break the zip even the Bugzilla can take it. > Just to be clear, I wrapped IDOM, with DOM.  Without preventing direct IDOM use, though. yes, bear with my English, I also meant what you did ... :-> Thanks! Tinny Lenny Hoffman wrote:  Hi Tinny, I created a zip containing the changed source.  I sent it to the mailing list, but it bounced it back because it was over 100K (it is 281K).  I looked at bugzilla, but it said that it forwards everything to the mailing list, so I was not sure that was the way to go.  Please advise -- should I break it up into 3 separate zips and send them separately? >> I am very interested in your changes, and I think it's a good idea to wrap the DOM with IDOM, Just to be clear, I wrapped IDOM, with DOM.  Without preventing direct IDOM use, though. Regards, Lenny ----- Original Message ----- From: Tinny Ng To: [EMAIL PROTECTED] Sent: Tuesday, January 22, 2002 6:29 AM Subject: Re: DOM_ IDOM_ Integration  Lenny, I am very interested in your changes, and I think it's a good idea to wrap the DOM with IDOM, and eventually fade out the old DOM implementation.  Actually I am also thinking to send the IDOM to W3C as one of the non-W3C referenced DOM C++ Binding.  I am working on a proposal ...... Would you please post your zip source to the mailing list or bugzilla?  We can review the changes in more detail, and see if we can adopt it to the Xerces-C++ code. Thanks! Tinny Lenny Hoffman wrote: Hi All, I went ahead and performed the refactoring.  The results are: IDOMCount and DOMCount now take the same amount of time.  Not a surprise, as the IDOM is now behind DOM, which only adds a lightweight smart pointer overhead.  If there is a better performance test for comparing, please let me know. The size of the release build of the VC6 DLL has been reduced to 1,364KB from 1,560KB.  This is indicative of my removing a large amount of code, mostly due to removing the DOM implementations. The DOM interface can still be used as always, except there were a few methods on DOM_Document that don't exist on IDOM_Document, so given the choice of implementing them in the IDOM or removing them, I simply removed them.  It looks like IDOM is truer to the DOM specification, and this seemed like the right way to go, even though I wanted to create an entirely backward compatible version of the DOM interfaces.  The methods could be added back and implementations provided on the IDOM side if that is the wrong decision.  The methods removed from DOM_Document were:     static DOM_Document   createDocument();     DOM_XMLDecl createXMLDecl(const DOMString& version,                             const DOMString& encoding,                             const DOMString& standalone); From inspecting the mail list archive, I learned that the developers of IDOM chose not to implement the equivalent to DOM_XMLDecl because it was non-standard and those parameters where eventually going to be attributes of the document.  Because of this I took the liberty to remove "XML_DECL_NODE  = 13" from IDOM_Node's and DOM_Node's Nodetype enumerations. I made all of my changes to an off-line copy of the source.  I can make it available to anyone interested in seeing it, and it would benefit me, and I believe many others, if the xerces group would adopt the changes.  As a review, here are the features. *  Users of the DOM interfaces now enjoy the same performance as those of the IDOM interfaces. *  Users can choose to work with either DOM or IDOM interfaces, and the choice is now more one of preference.  Though, those implementations that utilize reference counting may require the use of the DOM interface. *  Different DOM implementations can now be plugged in easily.  New implementations can provide classes derived from IDOM_* abstract base classes (overriding all methods) or existing ID*impl classes (overriding desired methods only).  For those new classes to be used all that is needed is a new DOM_Implementation/DOM_Document pair. *  Common components like the DOMParser can be used with any DOM implementation. *  Coupling has been removed from any specific DOM implementation, improving maintainability as well as providing flexibility. Here is a breakdown of the changes I made: I removed all "*impl*" files from the DOM subsystem. I added the following methods to IDOM_Node to enable IDOM implementations to keep track of in use nodes:     virtual void              addRef() {}     virtual void              removeRef() {} DOM_Node calls these methods on its IDOM_Node* fImpl member as appropriate in its constructors, assignment operators, and destructor.  The default implementation of IDOM simply does nothing in these calls, but other implementations may keep reference counts and removed from memory nodes that are no longer in use. I also added the same addRef()/removeRef() methods and support to NamedNodeMap, NodeList, Range, NodeIterator, and TreeWalker. Because implementations throw exceptions, I kept the IDOM versions of DOMException and RangeException and got rid of the DOM versions.  For backwards compatibility I kept the DOM_Exception and DOM_RangeException headers, though, and simply include the corresponding IDOM versions and add typedefs to gain DOM names for them. The DOM nodes all cloned strings being returned using DOMString, while IDOM returns const pointers to XMLCh.  The latter works for IDOM because it maintains returned strings in memory until the entire document is deleted, after which no one should be using strings obtained from it.  Not all back ends will have this policy, though, especially those that expand and collapse document sections as needed.  Thus I added  virtual bool doCloneStrings() const {return false;} to IDOM_Node that implementations can override should they need returned strings cloned.  I then rewrote DOMString to contain an XMLCh pointer that could be an alias or a copy, depending on how it is constructed.  It is constructed, of course, based on the result of doCloneStrings. I changed the implementation of DOMString to no longer use a string pool, but instead be a light wrapper for IDOM nodes that don't need their XMLCh's cloned, and to simply copy those that do.  I did this because the IDOM interface returning XMLCh instead of DOMString gave me the impression that its current implementation represented either unnecessary overhead, or something specific to the old DOM implemenation.  All DOMString mutators automatically create a copy (which the DOMString then owns) when called. I added IDOM_NodeFilter as a public base of DOM_NodeFilter so that it can be registered with IDOM_NodeIterator and IDOM_TreeWalker.  It implements IDOM_NodeFilter's acceptNode method by wrapping the IDOM_Node in a DOM_Node and passing it to DOM_NodeFilter's pure virtual acceptNode method for DOM_NodeFilter derived classes to override.  This keeps the DOM_ users unaware of the underlying IDOM_ implementations. I did nothing with NameNodeFilter.hpp; from what I could tell, it is incomplete code, there is no corresponding .cpp and its base class "NodeFilterImpl" does not exist. I made a couple of changes so that more than one DOMImplementation can exist at one time.  Each back end will need its own IDOM_DOMImplemetation derived class to create instances of its own IDOM_Document derived class.  These IDOM_DOMImplemetation derived classes may be implemented as a singleton, like IDDOMImplementation, or not.  I removed "IDOM_DOMImplementation *IDOM_DOMImplementation::getImplementation() const" and added a IDOM_DOMImplementation pointer as a member of IDDocumentImpl.  This way IDDocumentImpl instances can return the implementation that created them without assuming there is only one implementation in the system. The IDOMParser had a few areas where it was tightly coupled to various *Impl classes, which together being only one possible implementation of IDOM_* classes causes problems for using with other implementations.  I made the following changes to eliminate the coupling: 1.  Changed the parser's fDocument member's type from IDDocumentImpl* to IDOM_Document*. 2.  Added setErrorChecking and getErrorChecking virtual methods to IDOM_Document, which IDDocumentImpl overrides with its current methods. 3.  Added an addToNodeIDMap pure virtual method to IDOM_Document that takes an IDOM_Attr pointer.  Implementations can then store the map in whatever fashion they see fit.  I moved the code that creates and adds to IDDocumentImpl's node map to IDDocumentImpl. 4.  Added an overload of createDocumentType to IDOM_Document that takes a qualified name, public ID, and a system ID.  This matches up with IDDocumentImpl's overload. 5.  Added a setDocumentType pure virtual method to IDOM_Document which takes an IDOM_DocumentType pointer.  This matches up with that of IDDocumentImpl's. 6.  Changed the parser's fDocumentType member's type from IDDocumentTypeImpl* to IDOM_DocumentType*. 7.  Added protected pure virtual members to IDOM_DocumentType needed by IDOMParser (made IDOMParser a friend):     virtual void              setInternalSubset(const XMLCh *value) = 0;     virtual bool              isIntSubsetReading() const = 0;     virtual void              setIsIntSubsetReading(bool value) = 0; 8.  Changed all *Impl includes to include the IDOM_* base class, and changed all casts to *Impl to casts to IDOM_*. 9.  Added setReadOnly and isReadOnly pure virtual methods to IDOM_EntityReference. 10. Added setIngorableWhiteSpace protected pure virtual method to IDOM_Text and added IDOM_Parser as a friend. 11.  Added isIdAttr, setIsIdAttr and setSpecified as pure virtual methods to IDOM_Attr. 12.  Added protected pure virtual members to IDOM_Entity needed by IDOMParser (made IDOMParser a friend):     virtual void      setEntityRef(IDOM_EntityReference *) = 0;     virtual void            setPublicId(const XMLCh *arg) = 0;     virtual void            setSystemId(const XMLCh *arg) = 0;     virtual void            setNotationName(const XMLCh *arg) = 0; 13. Copied setPublicId and setSystemId from IDNotationImpl to IDOM_Notation. I added calls to addRef and removedRef for the current node and current parent just in case the document being built uses reference counting. I added an additional constructor to IDOMParser and DOMParser that takes an IDOM_DOMImplementation* so that users can define the type of document the parser builds. I gutted DOMParser and have it delegate to IDOMParser for most everything.  The only difference between DOMParser and IDOMParser is that it returns a DOM_Document instead of an IDOM_Document. I switched \schema\XUtil.cpp from using AttrImpl and ElementImpl to using IDOM_Attr and IDOM_Element. Regards, Lenny