--- Jeremias Maerki <[EMAIL PROTECTED]> wrote: > > 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, > > Well, the public API has to have > some way to control > the whole show.
You don't mean that literally--e.g.., a servlet programmer does not need useThisRenderer() and attachAreaTree() functions in a public API. (i.e., the public (embedded) API would be a strict subset of the functions available to the supervising octopus running the show) > This will automatically lead to a > little octopus if the > code is in ...fop or ...fop.api. But no problem with > another package. > For my discussion, apps=api (they're both supervising octopi). (Although I'm sure your package would be orders-of-magnitude cleaner and simpler!) > > 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. I agree with you that the apps package is hideous--but a pipeline may cleanup nearly all of it, providing it enforces the rules I mentioned earlier: a.) The only access between apps/api and the rest of the packages is via FOTreeBuilder and its "three" functions. b.) FOP is designed such that FOTreeBuilder *can* be directly instantiated via a servlet (even if we don't allow it). c.) Once so instantiated, no code within apps/api packages can be referenced. Via these rules, look at what gets removed from apps: (a) structure and layout handler are gone (those are past the FOTreeBuilder) (b) AWTStarter and PrintStarter are gone (those processing decisions are either handled by FOTreeBuilder or something that it delegates to.) (c) App class has *no* knowledge of renderers, element mappings, area trees, structure handlers. (d) Business logic is kept with each object, and not shared in multiple places. > > IMO FOTreeBuilder should just expose three > functions > > (perhaps another one for logging): > > 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. Excellent! We can leave that distraction out of the discussion. (Although they, in addition to threading issues, *do* appear to strengthen your argument on the need for a supervising class.) > > 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. I think it does, because it needs to know whether or not to generate an Area Tree, *which type* of structure handler, etc., also, since the Area Tree needs to know the render type, FOTreeBuilder will need to pass that information on to it via the pipeline. (Peter had said and you confirmed that the Area Tree still needs to know the rendering type for font sizes, etc.) Furthermore a different implementation of FOTreeBuilder may make different Area Tree decisions based on its render_type. > It should have nothing to > do with the > rendering aspect, especially since FO tree building > is independant of > the output format (wrt Renderers). Indeed, nothing to do with *rendering* but it does need to know the render_type as mentioned above. APPS/API knows nothing but FOTreeBuilder, which knows nothing but AreaTree, which knows nothing but the Renderers. So I also agree with you that FOTreeBuilder doesn't need to know about the Renderers. (but it could be so redesigned in the future, depending on the pluggable implementation of FOTreeBuilder, and this design more easily allows for that type of change.) > The render type > is better placed in a > class such as a > RenderingRun/Document/<whatever-we-call-it>. Sure, providing they pass that information on to FOTreeBuilder. ;) > The FO > tree > builder is (to me) a service that simply accepts a > SAX stream and builds > the FO tree. IMHO FOTreeBuilder is an object (C++/Java), not a service (C). > 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. If we were doing C programming--my fear is that the supervising class is going to end up eating FOP's object-oriented design and splitting the business logic too much in multiple places (just like apps currently does). (I guess I'll just have to trust the team to be disciplined in this regard! ;) > > The FOTreeBuilder should remain an inner service to > FOP, not exposed in > the public API, if you ask me. OK, a *very* thin wrapper (for those not needing any of the threading/logging goodies in apps/api): public class Fop extends FOTreeBuilder { } user's embedded code: Fop.setXSLFOStream(blah); Fop.setRenderType(RENDER_PS); myDoc = Fop.Run(); 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]