Glen Mazza wrote:
> I'd like to keep, however, at least for the time
> being, the naming convention in fop.apps with
> InputHandler as well. It's the command line "input
> handler" in apps, just like your abstract class is in
> apps.fo. If/when they start to conflict, we'll come
> up with better
Victor--
After looking over the new design, I like it. Please
keep your FOInputHandler abstract base class as-named.
FOTreeHandler also is a very good name.
I'd like to keep, however, at least for the time
being, the naming convention in fop.apps with
InputHandler as well. It's the command lin
Glen Mazza wrote:
> --- 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
--- 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 though
I don't feel strongly about this, but after trying to untangle some of the
relationships between classes and packages, and knowing that Glen is doing
more of the same, we may find it moderately useful to create a "parse"
package where classes like FOTreeBuilder (which needs to be renamed) and
FOInp
