[jdom-interest] Protected methods to make private
Bradley S. Huffman
hip at csa.cs.okstate.edu
Tue Jul 1 11:21:56 PDT 2003
Laurent Bihanic writes:
>
> Bradley S. Huffman wrote:
> > I don't think the following is any uglier than "if (atRoot) ..." that's
> > currently in comment(), startElement(), processingInstruction(). And SAXHan
> dler
> > now becomes reuseable, and JDOMResult becomes simpler :)
>
> Quite neat!
>
> There are some problems, though.
>
> Relying on endDocument to switch between result list and document won't work
> with XSLT processors.
> First, some XSLT processors (e.g. Oracle's) never invoke start/endDocument.
As I think about it, it makes sense since a processor wouldn't always know
what it's producing until the end of procecessing.
> Second, when the processor invokes endDocument (e.g. Xalan, Saxon, jd.xslt),
> the content of the result list may not be suitable to create a well-formed
> document as it may contain several elements.
So those processors will invoke startDocument and then invoke a series of
events that don't form a well-formed document, or invoke a endDocument
without a corresponding startDocument. Oooo, that sounds bad.
> A little bit more logic is needed to handle these cases. Maybe totally
> ignoring endDocument as in JDOMResult.FragmentHandler and moving all the
> Document construction logic in getDocument is the way to go
Delay creating a document until getDocument and if it throws a exception
catch it and return null, that should work. On a call to getResult would
you expect the document's content or for the returned List to be size == 1
and index 0 to contains a actual Document object? I think the later.
The default array size of 5 seems to be good 80/20 for most elements except
maybe the root element. So I also want to try buffering the root element's
content and delay the root element creation until endElement is invoke to
see if it helps on larger documents or just adds to much complexity.
Brad
More information about the jdom-interest
mailing list