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 more raw form.
> >
> Here's my thoughts on this (all seven of them!):
> 1) I'm not a big fan of the renaming because
> StructureHandler is not used for all possible render
> types.  Calling it FOInputHandler seems to imply that

Hmmm. I must be missing something. What render types is it not used for? It
is an abstract class that is subclassed by both the renderers that produce
an area tree (PDF, Postscript), and by the Structure Renderers (RTF, MIF).
In other words, it is used (I think) by anything that needs to parse an FO
document for input (hence its name).

> it's used whenever you are requesting an FO Tree to be
> built, i.e., always.  I didn't mind StructureHandler,
> but maybe FormattedHandler is also OK.

Actually it *is* used every time you are requesting an FO Tree to be built,
and in fact it is used for additional cases where an FO Tree is not built,
such as the Structure Renderers. That is what was driving me crazy -- I
couldn't figure out how LayoutHandler was a subclass of StructureHandler
!!??!! Now, one of the subclasses, FOTreeHandler (formerly LayoutHandler),
*is* used only by those renderers that actually need to build and use an FO

On the StructureHandler vs. FormattedHandler issue, AFAIK, the two concepts
are *opposites* in FOP's terminology. I might need to start a glossary page
to document this, so that we have a point of reference. Structure implies an
output format that is like XSL-FO in its character, i.e. it describes
general formatting properties, but doesn't do any layout. The two that we
support right now are RTF & MIF. The whole point of the renaming is that it
is used for much more than Structure.

Browsing through my SAX2 book just now gave me a bit of inspiration. It
breaks the SAX API into two pieces -- producers and consumers, which makes
sense. This is useful because the apps stuff (InputHandler and its concrete
subclasses) are producers, and the stuff I am working with in fo is
consumers. The book seems to equate "handler" with "consumer", which is the
same way I have been treating it. So maybe our apps classes would be better
named InputProducer, XSLTInputProducer, etc. I hate to get too hung up on
the naming stuff, but I spent about six hours of mind-numbing catatonic
thrashing yesterday figuring out that StructureHandler had nothing to do
with our concept of Structure, so I think it is worth some investment.

In all honesty, on your other 6 points my eyes glazed over. You are much
better educated than I about what is going on in that part of the code. To
conserve my limited bandwidth, I'll have to ignore it until I feel some pain
from there.

Victor Mote

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to