Once you've created the bug report, you can then add attachments.
Dave
"Lenny Hoffman"
<lennyhoffman@ear To: <[EMAIL PROTECTED]>
thlink.net> cc:
Subject: Re: DOM_ IDOM_ Integration
01/22/2002 01:38
PM
Please respond to
xerces-c-dev
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
