Umm...never mind, my original ideas are not proving to be the best on *both* of my proposed votes this week...quite humbling.
1) As for short-circuiting an XML stream into an XSLFO InputStream within the CommandLineOptions, Jeremias had pointed out that the buffering would be a performance/memory drawback. I saw command-line entering of xml & xsl files (instead of an xslfo: document) as purely a convenience factor for the user: i.e., so he wouldn't need to run Xalan first. However, the pipelining of the streams xml->xslfo->document does give a performance boost, i.e., TraxInputHandler is actually of legitimate use. Actually I don't mind the design of InputHandler and its subclasses now that I understand their purpose! We should probably still get rid of one of Trax/XSLTInputHandler, due to their duplicative functionality though. 2) The other vote, that below, of moving the parser creation to Driver, it appears the parsers are best kept with the InputHandlers still--primarily because the regular parser won't work with an non-xslfo XML stream. (TraxInputHandler supplies a different parser than FOInputHandler). The code can possibly still be centralized and simplified somewhat, by having an render() option that will take an InputHandler and extract the parser and stream itself. I'll look into that. Glen --- Glen Mazza <[EMAIL PROTECTED]> wrote: > I'll look into it. Actually, I got my complaint > wrong--I have less problem with something in apps > referencing the rest of the app (something it's > doing > 1,000 times already) than the *other* direction.) > > Glen > > --- Jeremias Maerki <[EMAIL PROTECTED]> > wrote: > > I don't see a problem with the apps package > > reference the configuration > > package. And it's almost the same code and with > the > > same semantics > > everywhere so this would actually reduce code. > > > > On 21.07.2003 18:20:30 Glen Mazza wrote: > > > Yes, I said InputHandler is where the parser is > > > created--I just want that moved over to Driver > > > (because driver is creating them to, with its > own > > > local instance, for external servlet usage). > This > > > will help Victor's API simplification, also > might > > help > > > us deprecate InputHandler a bit. > > > > > > When TRAX and XSLTInputHandler are out the > window > > > (AHHH!!! ;) I don't think we'll need the > > > FOInputHandler subclass anymore. Everything can > > go in > > > InputHandler. > > > > > > The parsers in CR and PP may have different > > properties > > > so for the time being, probably best for them to > > > continue creating their own parsers. At any > rate, > > I > > > wouldn't want code in the apps class to be > > referencing > > > CR or PP's packages, just for the sake of a > > parser. > > > (In the other direction may be OK, but we'll > wait > > > until the API is nailed down for that I guess.) > > > > > > Jeremias Maerki > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > For additional commands, email: > > [EMAIL PROTECTED] > > > > > __________________________________ > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month! > http://sbc.yahoo.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, email: > [EMAIL PROTECTED] > __________________________________ 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]
