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