--- Jeremias Maerki <[EMAIL PROTECTED]> wrote: > I'm a bit unhappy that you placed/left Session in > the apps package. I > would like to see the apps package deprecated as a > whole over time. I > would like a cli package that only contains the > stuff needed for the > command line and I'd like to have (wish, not a > demand) the main FOP api > in the org.apache.fop package. >
Instinctively, I wouldn't trust any code in the package root of org.apache.fop -- we wouldn't have a very modularized design that way (knowing FOP's current coding style, the main FOP API would then be accessing objects all through the packages, octopus-like, splitting of the business logic with the actual objects doing the work, inextricable from the XSL FO process.) FOP is more a pipeline to me: APPs package (CLI, TRAX/XSLTInputHandler, Avalonized API, Victor's ideas) --> FOTreeBuilder/Layout/Area Tree creation --> Rendering. IMO FOTreeBuilder should just expose three functions (perhaps another one for logging): 1.) SetXSLFOStream() (file or stream) 2.) SetRenderType() (those constants currently in Driver or CommandLineStarter) 3.) Run(). (returns a stream or file) You can have 500 methods of calling these functions within the apps package--it's all fine/OK, because they will only be able to work with FOTreeBuilder (apps will have no access to Renderers or Layout, etc.) and its three functions. Such an FOTreeBuilder may be getting to the heart of the XSLFO Spec: Input: XSLFO Stream, RenderType Output: Document and may be close to Xalan's approach, a team which has similar input/output requirements. Also, embedded Java code should be able to run without accessing the Apps class at all by directly calling those three functions in FOTreeBuilder. (Although we can certainly provide additional options in apps--but FOTreeBuilder should be all that is strictly needed.) Said another way, the processing paths of FOTreeBuilder, once instantiated in embedded code, should not access *any* functionality in the apps package, because apps is to the left of the pipeline. > And then I'm a bit unhappy about your terminology: > Session, Document, > RenderContext... Session and Document seem like > "rubber terms" to me. > Your Session looks very much like a > FOProcessorFactory (analog to > TransformerFactory). A session to me is a > short-lived object used during > one transaction. I think we should get consensus on > the terminology > first. > Again, I don't care much about what's in the app package, but I think the idea of a one-way FOTreeBuilder with just those three/four functions exposed should be explored. In general, too much business logic is in the apps package, it evens knows about ElementMappings and Renderers -- it shouldn't have to work with anything that implementation-specific. Also, AWTStarter and PrintStarter appear to be in the wrong places, those should somehow be moved out of apps and be *past* FOTreeBuilder. Let FOTreeBuilder decide to activate those objects should it get an appropriate SetRenderType(). But my "mental model" in incomplete here...comments most welcome! 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]
