Previous email was sent before I was done <red face/>, please ignore for this one:
--- Victor Mote <[EMAIL PROTECTED]> wrote: > AreaTree > is not > renderer-specific, but RenderContext specific. So, > for example, the same > AreaTree can be used to generate PostScript and PDF > output. Are you sure? Please read http://marc.theaimsgroup.com/?l=fop-dev&m=105455951226310&w=2 (Peter, Jeremias' writing)--they appear to indicate that the area tree is dependent upon the specific renderer being used, because of the fonts. > Also, while currently it is true that the AreaTree > creation is somewhat > bound to the FOTree creation, that is one of the > things that I think we are > trying to change (I am anyway). currently it's: FOP -----> Driver -------> FOTreeBuilder | | | | | | | | | \/ | | AWT/Print \/ | Starter Structure Handler <---- As in (1) FOP class determines if the render_type requires an area tree, if so goes to App.Driver, else App.AWT/Print Starter. (2) Driver activates the FOTreeBuilder. (3) Based on the render_type, Driver determines the type of StructureHandler (AreaTree) that FOTreeBuilder should send SAXEvents to, and gives it to FOTreeBuilder. (4) FOTreeBuilder sends SAX events to the StructureHandler that was given to it by Driver. I wanted to move to: (1) Doc/Dri API/Apps --------> FOTreeBuilder ------> its Area Tree (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). 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. 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. 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. > If we > return control of that up to these Control/API > classes, we get a clean > separation of these tasks, add the option for > patient processing as well, > and add the possibility of pluggable layout. > I agree--splitting the business logic between multiple classes tends to create spaghetti code. Glen __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
