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

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]

Reply via email to