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]

Reply via email to