On 20.12.2003 15:17:52 Victor Mote wrote:
> First, my apologies for being so slow to respond. I am trying to clean up
> some of this old stuff that I had flagged for followup. I also looked in the
> CVS history & source, and it looks like you have not finished this yet.
Right. I still got 622 unread mails in my fop-dev folder. :-) So I guess
I simply forgot. Available time also influenced this.
> The answer to your question probably lies in understanding how and why
> getContentHandler() is used without also using render(). The FOTreeListener
> is only needed if the input document is parsed, and in fact is only needed
> if you want to break out of parsing to go do something at a higher level
> before returning (the normal SAX events are not affected at all). So:
> 1) if the process running getContentHandler() doesn't ever parse, don't
> bother registering the FOTreeListener
Does that ever happen? I would assume that anyone who calls
getContentHandler() will want to send SAX events. I don't think I
understand what you're trying to explain. Sorry.
> 2) if the process running getContentHandler() doesn't care about being
> notified about the end of a PageSequence (which is the only FOTreeListener
> event that is *unique*), don't bother registering the FOTreeListener
Ok, I guess that is something that was introduced by your LayoutStrategy.
Would you explain to me what you mean by "process" in this context?
> 3) otherwise, have it wrap its parsing code inside of the following (which
> is what is wrapped around parser.parse in render() now):
> <before>
> if (foInputHandler instanceof FOTreeHandler) {
> FOTreeHandler foTreeHandler = (FOTreeHandler)foInputHandler;
> foTreeHandler.addFOTreeListener(currentDocument);
> }
> </before>
>
> <after>
> if (foInputHandler instanceof FOTreeHandler) {
> FOTreeHandler foTreeHandler = (FOTreeHandler)foInputHandler;
> foTreeHandler.removeFOTreeListener(currentDocument);
> }
> </after>
>
> Better yet, refactor both of the above code snippets into methods that can
> be called more simply, since this code would now be used more than once.
As methods of Document?
> Just looking at what is left in render(), I don't quite follow why it would
> ever *not* be used if parsing will take place. The only thing left in there
> is parser.parse(), the above code that it is wrapped in, and the code to
> *not* parse based on the LayoutStrategy's wishes. Since the parser itself
> can be passed as a parameter, it seems like anybody parsing could/would use
> it. If you will describe the use case(s) a bit, I'll try to be of more help.
Use cases that are not using render? Most prominent use case is Cocoon
which build a SAX pipeline where FOP can be the end of that pipeline. So
Cocoon needs a ContentHandler. Cocoon will not be able to call the
render() method. Personally, I have never used FOP's render() method as
a FOP user. I've always worked with getContentHandler(). I guess the
Cocoon use-case should be enough to convince you that the
getContentHandler() is necessary.
> Part of what is making this a bit ugly is that render() really belongs in
> the Document class, but I don't think that can be done until FOP's API
> issues are resolved.
Another top-priority todo item on my list that I haven't had time for,
yet. *sigh*
Jeremias Maerki
