Re: [VOTE] Centralize parser creation/Simpler internal rendering calls
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]
Re: [VOTE] Centralize parser creation/Simpler internal rendering calls
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]
Re: [VOTE] Centralize parser creation/Simpler internal rendering calls
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]
Re: [VOTE] Centralize parser creation/Simpler internal rendering calls
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.) Glen --- Jeremias Maerki <[EMAIL PROTECTED]> wrote: > Hmm, generally +1. There are even more places where > a parser is created. > Eclipse gives me: InputHandler, ConfigurationReader > and > hyphenation.PatternParser. Could you switch the > parser instantiation > over to ConfigurationReader and delete the > createParser() methods in > InputHandler and PatternParser? That centralizes > things and will make it > easier later to switch to the Avalon parser > factories. And it's a pretty > good place for now (not being exclusively useful for > the external API > classes). > > But as mentioned in my earlier mail, I almost > exclusively use the > Transformer part of JAXP for XML parsing: > InputSource --> Source. But > that's personal preference. > > On 21.07.2003 17:50:19 Glen Mazza wrote: > > We're currently creating equivalent XMLReaders for > the > > FO Tree in two places, the Driver class (within > the > > run() method) and within the InputHandler class > > get/createParser() methods (with an additional > > SetParserFeatures() within the Starter class). > > > > I'd like to centralize all this into the Driver > class, > > and have a single createParser() function in one > > place. I realize that Driver may be going out the > > window soon, so whatever replaces it will have > full > > control over parser-creating duties. > > > > With this change, all internal calls of the > > Driver.render() functions will no longer need to > > create a parser to send to the Driver class prior > to > > calling render(). Currently AWTStarter, > PrintStarter, > > CommandLineStarter and FOPTask are all creating > > parsers prior to calling render(), as below for > > CommandLineStarter: > > > > XMLReader parser = > inputHandler.getParser(); > > setParserFeatures(parser); > > render(parser, inputHandler.getInputSource()); > > > > They will have a new function to call (we'll keep > the > > above in case it's used externally): > > > > public synchronized void render(InputSource > source) > > > > that will eliminate each caller's need to create a > > parser first. > > > > Here is my +1. > > > 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]
Re: [VOTE] Centralize parser creation/Simpler internal rendering calls
Hmm, generally +1. There are even more places where a parser is created. Eclipse gives me: InputHandler, ConfigurationReader and hyphenation.PatternParser. Could you switch the parser instantiation over to ConfigurationReader and delete the createParser() methods in InputHandler and PatternParser? That centralizes things and will make it easier later to switch to the Avalon parser factories. And it's a pretty good place for now (not being exclusively useful for the external API classes). But as mentioned in my earlier mail, I almost exclusively use the Transformer part of JAXP for XML parsing: InputSource --> Source. But that's personal preference. On 21.07.2003 17:50:19 Glen Mazza wrote: > We're currently creating equivalent XMLReaders for the > FO Tree in two places, the Driver class (within the > run() method) and within the InputHandler class > get/createParser() methods (with an additional > SetParserFeatures() within the Starter class). > > I'd like to centralize all this into the Driver class, > and have a single createParser() function in one > place. I realize that Driver may be going out the > window soon, so whatever replaces it will have full > control over parser-creating duties. > > With this change, all internal calls of the > Driver.render() functions will no longer need to > create a parser to send to the Driver class prior to > calling render(). Currently AWTStarter, PrintStarter, > CommandLineStarter and FOPTask are all creating > parsers prior to calling render(), as below for > CommandLineStarter: > > XMLReader parser = inputHandler.getParser(); > setParserFeatures(parser); > render(parser, inputHandler.getInputSource()); > > They will have a new function to call (we'll keep the > above in case it's used externally): > > public synchronized void render(InputSource source) > > that will eliminate each caller's need to create a > parser first. > > Here is my +1. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[VOTE] Centralize parser creation/Simpler internal rendering calls
Team, We're currently creating equivalent XMLReaders for the FO Tree in two places, the Driver class (within the run() method) and within the InputHandler class get/createParser() methods (with an additional SetParserFeatures() within the Starter class). I'd like to centralize all this into the Driver class, and have a single createParser() function in one place. I realize that Driver may be going out the window soon, so whatever replaces it will have full control over parser-creating duties. With this change, all internal calls of the Driver.render() functions will no longer need to create a parser to send to the Driver class prior to calling render(). Currently AWTStarter, PrintStarter, CommandLineStarter and FOPTask are all creating parsers prior to calling render(), as below for CommandLineStarter: XMLReader parser = inputHandler.getParser(); setParserFeatures(parser); render(parser, inputHandler.getInputSource()); They will have a new function to call (we'll keep the above in case it's used externally): public synchronized void render(InputSource source) that will eliminate each caller's need to create a parser first. Here is my +1. Thanks, Glen __ 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]
