Victor Mote wrote:
I guess I don't
understand the need for FOProcessorFactory, which seems to be an unnecessary
complication for the user.

It has something to do with the GoF Factory pattern. This means you can choose the implementation of the FOProcessorAPI by setting a Java property, or some similar mechanism at run time instead of choosing it at compile time. Granted, this seems of not much use given that FOP will be the only implementation at least for some time. There is another aspect: the FOProcessorFactory holds a default configuration and is a mechanism to quickly create preconfigured FOProcessor objects. You just can't use a single FOProcessor, because it holds a state while rendering and is therefore not MT safe in itself. Unless you can live with blocked threads this means you have to create a FOProcessor for every thread. Furthermore you might want to keep FOProcessor objects some time around after rendering has finished in order to inquire the number of rendered pages or whatever useful data the processor can supply then.

RenderContext is only useful if you are trying to reuse an AreaTree for
multiple output options. I am frankly confused right now about whether the
dev team even wants to try to do that.

I think we have a few slightly more pressing problems: - getting layout up to conformance - make FOP MT safe - improving the API to ease embedding (including Java2D embedding) - improve performance and reduce memory consumption

Adding multiple output streams is certainly fun but I suspect the
bulk of the current users would be more interested in one of the
points above. And somehow I have the feeling that your approach could
easily get in the way, in particular I wouldn't like if it would
*increase* memory usage in general.

It looks like you are pushing the data that I envisioned in Document
and RenderContext down to RenderType/FOPResult. The net effect is that it
can't be reused.
Why can't it be reused?

1. complexity. In addition to the Factory issue already mentioned, I think
there is some benefit to arranging the data more intuitively for the user.
Users should be able to recognize certain patterns, like the ones
used in JAXP.


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]

Reply via email to