Mircea Toma wrote:
Hi,Some feedback on the split : I'm running Cocoon in constrained environments (see [1]) and these applications only use SAX events. For this, we wrote a specific Parser implementation that doesn't implement the DOM-related methods to reduce the code size. But the class still keeps a dependency on org.w3c.dom.Document.
From: "Carsten Ziegeler" <[EMAIL PROTECTED]>
;)Yes, I thought of that, too - and wanted to do it today. (To be precise,....My personal opinion would have been to rename the interfaces to SAXParser and DOMParser to avoid having to use fully qualified classnames because of the same name.
it wasn't me that started this splitting, but that's not important).
When I did the refactoring I thought about this a lot. In my opinion there
is no need for a DOMParser at all. Most of the DOM parsers base their lexing
functionality on a SAX parser and use a DOM builder after that to create the
XML structure in memory. In our case the Parser interface is doing the
lexing while the DOMHandler is responsible for creating the DOM structure.
You can see this as a SoC pattern or you can see it as an inefficient
pattern :)
Yes, the current DOMHandler implementation is using JAXP classes to do the
transformation but that's just because I'm lazy....
So I fully second the split, which removes the need for this hack !
Sylvain
[1] http://outerthought.net/gettogether/06%20-%20presentation%20-%20sylvain.pdf
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
