parsing package

[Victor Mote <vi...@outfitr.com>]

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
FOInputHandler (formerly StructureHandler) can live. We have parsing which
is not related to FO Tree building, and it may be useful to have a place to
put that. Some of the apps classes Glen has been working on might fit there
as well (InputHandler, TraxInputHandler, XSLTInputHandler, and
FOInputHandler).

Oops, I see that I now have duplicated the name FOInputHandler (one in apps,
one in fo). It doesn't cause any problems that I know of, but I will try to
fix it later today or tomorrow. 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.

Victor Mote


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

RE: parsing package

[Victor Mote <vi...@outfitr.com>]

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 names in the apps package--I just don't
> want to come up with an incomplete name right now.

That's fine with me. I don't want to be churning names either. Even if the
names come in conflict, we can fully qualify them for the compiler. After
the dust settles on your changes, we just need to remember to clean up one
or the other of the names to reduce confusion for the humans.

Victor Mote


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

RE: parsing package

[Glen Mazza <gr...@yahoo.com>]

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 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 names in the apps package--I just don't
want to come up with an incomplete name right now.

Thanks,
Glen


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

RE: parsing package

[Victor Mote <vi...@outfitr.com>]

Glen Mazza wrote:

> --- Victor Mote <vi...@outfitr.com> 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
tree.

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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: parsing package

[Glen Mazza <gr...@yahoo.com>]

--- Victor Mote <vi...@outfitr.com> 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
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.

2) I'm starting to like InputHandler's design quite a
bit.  I'm thinking of expanding InputHandler a bit to
hold all the document-related properties requested on
the command line in generating a document. In
particular, to hold these parameters (from
CommandLineOptions):

--Render Type
--Render Options (we just have one currently in CLO)
--Language (currently just used by AWTRenderer)
--Output File Name (just the file name, not the output
itself) (is null for AWT and AWTPrint render types)

3) AWTRenderer is our only "reentrant" renderer,
because it has a reload button.  Such a button is
currently only in use for the command-line
(nonembedded) operation (apps.AWTStarter activates
it.)

I'd like to come up with an overloaded constructor for
AWTRenderer that takes the above InputHandler. 
(embedded use will not use this, there will continue
to be no reload button.)  Hitting "Reload" will cause
the renderer to regenerate given the InputHandler. 
(Currently it has AWTStarter run itself again).  If I
can have AWTRenderer make the render request
itself--no guarantees yet--we won't need AWTStarter
anymore.  And with that, we won't need Starter nor
CommandLineStarter either--it can go into
apps.Fop.main().

4) I've found FOInputHandler to be fine.  It nicely
extends the above by adding an FOInputFile name as
well.  It creates an XSLFO Parser, an XMLReader
instance.

5) XSLTInputHandler and TraxInputHandler are synonym
classes with the former just wrapping the latter. 
Their difference from InputHandler is that (1) provide
an XML & XSL FO Parser combination in the form of a
XMLFilter (a subclass of XMLReader, I believe). and
(2) they have XSLT and XML file name member variables.

I would like to get rid of TraxInputHandler,
however--because it's less historically used between
the two and also its name is technology-dependent.

Hence, all the functionality of TraxInputHandler
moves, function by function, into XSLTInputHandler and
TraxInputHandler gets removed.

6) My perceptions may be wrong here, but there appears
to be *another*, new InputHandler option: 
DOMInputHandler!  Sitting in apache.fop.tools there is
a DocumentInputSource (1/2 of DOMInputHandler) and
DocumentReader (i.e., its XMLReader, the other 1/2). 
Coming up with DOMInputHandler combines these two
files and also simplifies Driver a bit (you can see
some of the render() functions there handle the
Document (DOM) and FO/XSLT cases differently, with
this change this *might* no longer be needed.)

7) I like keeping the parser with each type of
InputHandler because it keeps a lot of the processing
code independent of the specific InputHandler
subclass:

(new function created on Sunday, in Driver):
public synchronized void render(InputHandler
inputHandler)
throws FOPException {
   XMLReader parser = inputHandler.getParser();
   inputHandler.setParserFeatures(parser);
   render(parser, inputHandler.getInputSource());
}

This code works the same for XSLTInputHandler and
FOInputHandler (and DOMInputHandler, if we come up
with it.)  We can avoid the "if this is the input, use
this parser; else if that is the input, use that
parser", etc.--type coding.  [Incidentally,
setParserFeatures() above may not be needed, it should
be internal to the getParser() function call; I'll
look into it.]

Comments welcome!

Thanks,
Glen


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org