--- Victor Mote <[EMAIL PROTECTED]> wrote: > Glen, what are your > plans for > apps/FOInputHandler? Will it be going away or get > renamed anyway? I have > been using "Handler" as related to SAX events, and > it looks like we have it > also being used as I/O in a more raw form. >
Here's my thoughts on this (all seven of them!): 1) I'm not a big fan of the renaming because StructureHandler is not used for all possible render types. Calling it FOInputHandler seems to imply that it's used whenever you are requesting an FO Tree to be built, i.e., always. I didn't mind StructureHandler, but maybe FormattedHandler is also OK. 2) I'm starting to like InputHandler's design quite a bit. I'm thinking of expanding InputHandler a bit to hold all the document-related properties requested on the command line in generating a document. In particular, to hold these parameters (from CommandLineOptions): --Render Type --Render Options (we just have one currently in CLO) --Language (currently just used by AWTRenderer) --Output File Name (just the file name, not the output itself) (is null for AWT and AWTPrint render types) 3) AWTRenderer is our only "reentrant" renderer, because it has a reload button. Such a button is currently only in use for the command-line (nonembedded) operation (apps.AWTStarter activates it.) I'd like to come up with an overloaded constructor for AWTRenderer that takes the above InputHandler. (embedded use will not use this, there will continue to be no reload button.) Hitting "Reload" will cause the renderer to regenerate given the InputHandler. (Currently it has AWTStarter run itself again). If I can have AWTRenderer make the render request itself--no guarantees yet--we won't need AWTStarter anymore. And with that, we won't need Starter nor CommandLineStarter either--it can go into apps.Fop.main(). 4) I've found FOInputHandler to be fine. It nicely extends the above by adding an FOInputFile name as well. It creates an XSLFO Parser, an XMLReader instance. 5) XSLTInputHandler and TraxInputHandler are synonym classes with the former just wrapping the latter. Their difference from InputHandler is that (1) provide an XML & XSL FO Parser combination in the form of a XMLFilter (a subclass of XMLReader, I believe). and (2) they have XSLT and XML file name member variables. I would like to get rid of TraxInputHandler, however--because it's less historically used between the two and also its name is technology-dependent. Hence, all the functionality of TraxInputHandler moves, function by function, into XSLTInputHandler and TraxInputHandler gets removed. 6) My perceptions may be wrong here, but there appears to be *another*, new InputHandler option: DOMInputHandler! Sitting in apache.fop.tools there is a DocumentInputSource (1/2 of DOMInputHandler) and DocumentReader (i.e., its XMLReader, the other 1/2). Coming up with DOMInputHandler combines these two files and also simplifies Driver a bit (you can see some of the render() functions there handle the Document (DOM) and FO/XSLT cases differently, with this change this *might* no longer be needed.) 7) I like keeping the parser with each type of InputHandler because it keeps a lot of the processing code independent of the specific InputHandler subclass: (new function created on Sunday, in Driver): public synchronized void render(InputHandler inputHandler) throws FOPException { XMLReader parser = inputHandler.getParser(); inputHandler.setParserFeatures(parser); render(parser, inputHandler.getInputSource()); } This code works the same for XSLTInputHandler and FOInputHandler (and DOMInputHandler, if we come up with it.) We can avoid the "if this is the input, use this parser; else if that is the input, use that parser", etc.--type coding. [Incidentally, setParserFeatures() above may not be needed, it should be internal to the getParser() function call; I'll look into it.] Comments welcome! Thanks, Glen __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]