On 20.06.2003 21:23:50 Glen Mazza wrote: > (1) Doc/Dri/whatever feed the FOTreeBuilder the xslfo > and the render_type, calls Run() > > (2) Based on the render_type FOTreeBuilder either > creates an area tree of its choosing, or doesn't > (AWT/Print).
Even with AWT/Print an Area Tree is generated. > If it does, it determines *which* type > of area tree to create (Structure or MIF or the other > one)--based again on the render_type. The business > logic for this would be in FOTreeBuilder. But no area tree is generated when a StructureHandler (RTF/MIF) is active. > Regardless of area tree decision, it is responsible > for generating the report via its Run() function. > I.e., the area tree may just be a local variable of > its run() rather than its current status as a member > variable. > > Your idea is (non-graphical, I'm getting tired ;): > > <document class> > foTree = foTreeBuilder.createFOTree(); > areaTree = areaTree.createAreaTree(foTree); > > You are correct--this is *very* elegant--problem is, > from Keiron's writing, we just can't separate the > FOTree from the area tree because of an unacceptable > performance hit. It doesn't need to be separated. But the building (!) of the FO tree is separated from other code like layout or RTF generation. > > See: > http://marc.theaimsgroup.com/?l=fop-dev&m=105270887501490&w=2 > > [EMAIL PROTECTED] FOTree needs to encapsulate the > AreaTree, I thought the next best solution would be to > divorce your document from knowledge of the AreaTree, > rather than have both classes point to it. > > Here's food for thought--if we rename FOTreeBuilder to > XSLFOProcessor, perhaps you would have less concerns > about feeding it the render type. We can make this > centrally-located class the "octopus" of the > application, rather than the left-side > Document/API/APPs class. YOU GET IT! Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
