Thanks Simon for your comments.
--- Simon Pepping [EMAIL PROTECTED] wrote:
On Tue, Jul 13, 2004 at 12:16:22AM -,
[EMAIL PROTECTED] wrote:
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
abstractions.)
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
SAX
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
FOTreeBuilder!)
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 500265LOC
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.
Glen
