(Hmmm...I'm supposed to be learning Cocoon right now,
but am already suffering FOP-withdrawal.  Apache's got
me good...  ;)

[just removed the namespace-prefixes issue you were
mentioning earlier, btw.]

FOFileHandler.createParser() is just a simple static
function that generates a parser.  It can be placed in
any class, and is not something that needs to be 
inherited. (Actually, the hyphenation class'
PatternParser also creates a parser, although it could
use the one in FOFileHandler as well.)

InputHandler has a abstract getParser() method which
is used by Driver et. al.  This method *does* need to
be overridden in each of the base classes, and of
course it is.  

It just so happens, but is not necessarily required,
that the current implementation of XSLTInputHandler
uses the createParser() of FOFileHandler for its
implementation of getParser().  This is just an
implementation detail. 

XSLTInputHandler's getXMLFilter() (called by its
// Create an XMLReader.
XMLReader parser = FOFileHandler.createParser();

I preferred the direct reference to the FOFileHandler
method (as opposed to simple inheritance) for reasons
of documentation:  this way, we're clearly stating
that XSLTInputHandler is using FOFileHandler's parser
as part of its XMLFilter.

(Also, at the time I was doing this, I was planning on
having a DOMInputHandler--but was running into
difficulty doing so--that I believe would have caused
a createParser() to not have been relevant in the base


--- Peter West wrote:
> Glen at al.
> One of the things I noticed when I was looking for
> ways to bring the 
> apps classes of alt-design and HEAD closer together
> was that the 
> createParser method seemed to belong in
> InputHandler,
> because it is 
> required by both subclasses.  Any reason why it
> isn't
> there?
> Peter

Reply via email to