Reorganization of the DOM implementation

[Arnaud Le Hors <le...@us.ibm.com>]

Hi all,
no, I'm not dead yet, I just got new responsibilities which turn out to
prevent me from doing much Xerces work. However, I can only stay away
from doing any coding for so long, so I managed to do some work on the
DOM implementation. Here is the log for those who don't receive the CVS
logs.


This new implementation supports two different DOMImplementation
classes. CoreDOMImplementationImpl, along with CoreDocumentImpl, only
supports DOM Core. DOMImplementationImpl, along with DocumentImpl,
inherits from the Core classes and adds support for optional modules
(MutationEvents, Ranges, Traversal) as well as the Deferred DOM.

Not much code has actually changed, but quite a lot of code has been
moved around. In particular, all the event code has been moved to
DocumentImpl. Instead of firing events directly, other classes now
simply notify the document of mutations. This allows us to have a core
document class which does nothing in response to these notifications,
and a more complete class which fires mutation events as well as update
ranges and iterators if there are any.

The net result is that one can make a jar which only contains the core
DOM, that is half the size of the complete DOM. The code is also cleaner
although fully backward compatible. Existing applications using the
DOMImplemenationImpl and DocumentImpl classes will keep working just
fine.

In addition, although the gain can't be huge (because I already
optimized the code quite a bit ;-), the Core DOM can only be smaller in
memory and faster. At the same time memory consumption and performance
remain the same for the complete DOM. I actually noticed some small
difference in performance (~2%) but it turns out to be either a loss or
a gain depending on the jvm, so...

When we implement the DOM Level 3 Registry mechanism one will be able to
dynamically select one implementation or the other, depending on the
features it needs.

As an extra bonus the deferred DOM is a clean layer on top of the other
classes again, and can therefore be left out if desired.


Enjoy! :-)
-- 
Arnaud  Le Hors - IBM, XML Standards Strategy Group / W3C AC Rep.

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org