On 17.06.2003 21:28:29 Glen Mazza wrote: > 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.)
Not necessarily. Well, the public API has to have some way to control the whole show. This will automatically lead to a little octopus if the code is in ...fop or ...fop.api. But no problem with another package. > FOP is more a pipeline to me: > > APPs package (CLI, TRAX/XSLTInputHandler, Avalonized > API, Victor's ideas) --> FOTreeBuilder/Layout/Area > Tree creation --> Rendering. Uh, thanks for that one. It's a very nice show why the current apps package is a mess. SoC (Separation of Concerns) would suggest not to mix thing like CLI, public API and inner communication classes. > IMO FOTreeBuilder should just expose three functions > (perhaps another one for logging): Logging, at least in Avalon-land, is a lifecycle aspect (through the LogEnabled interface). The methods below are lifestyle methods. Lifecycle != lifestyle. It's best to talk about lifestyle primarily and leave the lifecycle (instantiation, logging, configuration, initialization) to a different discussion. Helps keeping the focus, I believe. The lifecycle can eventually be handled automatically by a container (such as Fortress or Merlin). Leaves you to care about the lifestyle (=functionality). > 1.) SetXSLFOStream() (file or stream) > 2.) SetRenderType() (those constants currently in > Driver or CommandLineStarter) > 3.) Run(). (returns a stream or file) This mixes concerns. A render type does not belong in a class called FOTreeBuilder. The name already implies that the class is responsible for building the FO tree. It should have nothing to do with the rendering aspect, especially since FO tree building is independant of the output format (wrt Renderers). The render type is better placed in a class such as a RenderingRun/Document/<whatever-we-call-it>. The FO tree builder is (to me) a service that simply accepts a SAX stream and builds the FO tree. The layout engine, another (coarse grained) service, will then access the FO tree to do the layout. This is all kept together by a "supervising" class. At least, that's my personal high-level view of it. > 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. The FOTreeBuilder should remain an inner service to FOP, not exposed in the public API, if you ask me. The public API, IMHO, should be an easily understandable construct that masks the internal complexity from the user. Driver already does that today, it's just a bit too tightly packed and not focused on as little as possible. We need to disentangle that class to make it more like the JAXP API. > (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. Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
