--- 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]

Reply via email to