Thanks Simon for your comments.

--- Simon Pepping <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 13, 2004 at 12:16:22AM -0000,
> > gmazza      2004/07/12 17:16:22
> >   Log:
> >   1.) Combined the AreaTree and FOTreeHandler into
> a new AreaTreeHandler
> >   object.  FOTreeHandler was primarily acting as
> an AreaTreeHandler,
> >   and AreaTree had a 1-to-1 relationship with it. 
> Comments most welcome.
> This change seems to cross the border between FO
> tree and area tree. 

Not really, FOTreeHandler already had an AreaTree
object as its child.  I incorporated the two, and am
now deeming *its* child, apps.AreaTreeModel, as the
abstraction of our area tree.  (Using SAX, we don't
really have an FOTree or an Area tree, just

> AreaTree had no reference to the fo package (apart
> from a reference to
> fo.extensions). AreaTreeHandler extends a class in
> the fo package and
> refers to fo/PageSequence.

Yes, it now receives messages from fo/PageSequence and
activates the AreaTreeModel when it receives them.  

> FOInputHandler implements a number of methods of the
> contenthandler, which is between the fo file and the
> FO tree. 

Err--not at the time of invocation of startFOThis()
and endFOThat() within FOInputHandler--at that stage,
we're now at FOtree moving forward (-->MIF, or -->RTF,
or -->AreaTree.)  (The spec's model is "DOM", but
we're really running "SAX".)

> The area
> package now inherits these methods. 

Yes, like MIFHandler and RTFHandler, the other two
subclasses of FOInputHandler, and digesters of
FOTreeBuilder, AreaTreeHandler now inherits these
methods, because it handles SAXEvents (again, like
MIFHandler and RTFHandler).

The nomenclature was deliberate--while all three
actually were "FOTreeHandlers"--indeed, they all need
an FOTree--only a certain segment of render types need
an area tree, and for those, AreaTreeHandler's name is
nicely self-documenting.  

> AreaTreeHandler
> throws
> SAXExceptions. This is a parser based exception
> type.

Indeed--needs them just as much as MIFHandler and
RTFHandler do.

> FOTreeHandler.endPageSequence is the FO tree's
> activation of a new
> episode of area tree building. 

No, it was an *Area Tree-needing render type (i.e.,
PDF, PS)* activation of a new episode of area tree
building.  We just called it "FOTreeHandler", but it
really served as an AreaTreeHandler. (Our
"FOTreeHandler", if anything, was actually

> Now the area tree
> activates itself,
> based on an event in the FO tree.

I didn't see it that way, because my view of the
AreaTree is actually apps.AreaTreeModel, the child of
AreaTreeHandler.  But there is indeed more circularity
now (PageSequence used to interact with both
FOTreeHandler and AreaTree, now it interacts just with
AreaTreeHandler)--not necessarily a bad thing, and may
be one of the keys to solving XSL.

When AreaTreeHandler gets an indication from an
fo:page-sequence that it is finished, it activates
AreaTreeModel to start the generation of areas.  It is
very similar to what MIF and RTFHandler would do when
they get messages from the FOTree: act on the data. 
In addition to renaming it, I moved this out of the fo
package and into AreaTree package, because I thought
that the proper home of "AreaTreeHandler", just like a
RTF rendering package is the proper home of
RTFHandler, and the MIF one is of "MIFHandler".  It
just didn't belong in the fo-directory, because if we
used that logic all three should belong there.

Also, in merging the two I was able to remove a lot of
code that dealt with communication between the
two--moving out this administrative code dropped the
combined size by about a third (IIRC 500&265LOC
before, 465LOC after.) It does help in comprehension.

Take a second look at it--you may find it has a lot of
potential for our future work.  And we'll get input
from others.

Sorry for the long post.


Reply via email to