On 18.06.2003 22:36:12 Glen Mazza wrote:
> > 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).
I'm talking about Avalon-style services. These are components that
implement a certain work interface. In the background there's a main
implementation class (either alone or representing a whole subsystem).
The interface helps to decouple the whole system (FOP). Loose coupling
is the keyword here. The interface also makes it easy to switch
implementations (for example: font sources, layout engines, whatever).
FOTreeBuilder, in my view of things, will change to be an interface, not
a Java object. You'll then have an implementation of the FOTreeBuilder
(ex. DefaultFOTreeBuilder) which provides the service of building an 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.
>
> If we were doing C programming
We don't.
>--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();
Please not. This encourages tight coupling between the main classes of
FOP IMHO. Avalon encourages the assembly of a system (several
services/subsystems bound together to build a bigger system, association
instead of subclassing). The subsystems get separated by well-designed
interfaces that encourage SoC (separation of concerns). That's why I'd
like to see FOTreeBuilder as a service:
FOTreeBuilder could look like this:
public interface FOTreeBuilder {
void setStructureHandler(StructureHandler handler);
ContentHandler getContentHandler();
FONode getRootNode();
boolean isEmpty();
void reset();
}
or
public interface FOTreeBuilder {
/** Build an FO tree and store it in the process controller class.*/
ContentHandler buildFOTree(ProcessorRun/Document/<whatever>, StructureHandler
handler);
}
That's all it does. Already today, it's quite a light-weight thing. It's
Victor's new classes (Document, for example) that will keep the whole
thing together, in as little number of places as possible. This improves
decoupling and centralizes control which in the end should make the
whole thing easier to understand.
I really don't know if this concrete example will work out exactly like this.
I didn't even investigate how this will fit with Peter's work. I'm just
getting the impression that you're going into a problematic direction by
off-loading too much on something like the TreeBuilder.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
