DOMParser

[Dirk Brenckmann <Di...@gmx.de>]

Hi there,

my name is Dirk Brenckmann and I'm new to your list.
I'm currently stuck with finding a simple way to attach additional features to nodes
and elements created by xerces. I do not want to create my very own document
implementations, because I do not want to loose the xerces capabilities coming 
along with its default implementation (deferrence of node creation etc.).

First problem on my list is: org.apache.xerces.parsers.DOMParser

If you take a look at the method:

	startDocument(...)

you'll find three ways of document creation. But: Just one of those
creations can be monitored by overwriting the method:

	createDocument(...)

Because one cannot really track the creation of a document, it becomes quite
difficult to simply monitor the creation of document nodes as well. (At least in 
the way xerces currently implements node creation). This is especially, because
Xerces needs to make a difference in creating "deferred" and "none deferred" 
nodes.

When using "deferrence", the creation of real nodes can be monitored within the
DeferredDocumentImpl class only. As far as I (think I) understood, it's the method:

	public DeferredNode getNodeObject(int nodeIndex)

In case of no deferrence, node creation can either be monitored within the
application specific document implementation - using the method:

	document.createElement(element.rawname)

or - if you use xerces DOM implementation:

	documentImpl.createElementNS(...)
  (in this case, document.createElement(element.rawname) will never(!) be called)

Lucky us, because we can use the parsers method to be triggered, independant
from the document implementation:

	abstractDomParser.createElementNode(...)

Problem: this does not work with deferred node creation (of course).

Being introduced to all these different ways of document and node creation, I finally
was lucky to find out the good news: There is exactly one consistent way to "not"
create nodes ... :-)

----------------------------------

Ok - here is an approach to a solution:

Enable adding a "NodeCeationListener" to the parser.
The parser then - dependant on deferrence or not - could decide to hand the listener(s)
on to the DocumentImpl (in case of deferrence) or to notify the listeners on it's own.
The listener then could/would be notified in any case of node creation.

I think such feature could easily be implemented without major changes in the 
current api. It would enhance xerces core implementaion flexibility and maybe
reduce the need for application specific document implementations.

-----------------------------------

Finally:

Being informed of node creation is just fine. Cool would be the possibility of somehow
"attaching" capabilities to a new node. I'm not talking about "getUserObject" stuff. I 
would like to make use of "differing node types" within one document. This would enable
the usage of Designpatterns like Facades and Proxys with nodes. DOM-Nodes then 
could become parts of applications...
Currently the use of Wrappers and Proxies is not possible, because starting with the
level of NodeImpl, xerces does not make use of any interfaces. There is no interface
description for the additional features that need to be implemented by a node to make it
work as NodeImpl or NodeChild within the default xerces document/node implementation.
This dramatically decreases modularity and reusability, because DOM Elements of the
xerces default implementation can only be used in the single way they were meant to
be used by xerces. Therefor I'd suggest the introduction of additional interfaces and a
refactoring of certain code parts, which currently do upcasts and direct calls to abstract
or concrete Node classes.
Such changes again, would not touch current compatibilities and usages but they could
efficiently increase flexibility, reusability and support a wider range of design patterns.


Currently I do not know how your project is organized, but if you are interested just let
me know how and I will be ready to "get involved"...

Dirk Brenckmann





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

Re: DOMParser

[Joseph Kesselman <ke...@us.ibm.com>]

>attach additional features to nodes and elements created by xerces.

Possible approaches:

1) See the DOM Level 3 "user data" feature; I believe Xerces has 
prototyped that functionality.

2) Plug in a new DOM implementation. (Simplest: Use Xerces as a SAX 
parser, feed its output into a SAX-driven DOM builder of your choice.) It 
is possible, though not easy, to subclass the Xerces DOM; you may find it 
simpler to copy that code and modify it.



______________________________________
Joe Kesselman, IBM Next-Generation Web Technologies: XML, XSL and more. 
"may'ron DaroQbe'chugh vaj bIrIQbej"  ("Put down the squeezebox and nobody 
gets hurt.")


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