> Here are some ideas about how we could do the configuration for FOP.
> Comments are welcome.
> Use this class and various supporting classs (already in avalon
> framework jar):
> From a brief look at how this works it should be quite easy to use. We
> just need to decide on an appropriate xml structure. I have attached an
It is. I'm using this stuff every day.
> This can be used either with an xml file on the command line or through
> embedding, eg. cocoon could pass a fop configuration class.
> If the classes are not configured then default values are used.
> Configurable classes:
I'd like to elaborate because I'm not sure that everyone is familiar
with Avalon's concepts: These classes will implement the "Configurable"
interface from Avalon. Following the concept of IoC (those who are not
familiar with this term, please look up Avalon docs) the configuration
is set by the container (ex. Cocoon or our command-line wrapper) on the
child (Driver, Renderer etc.).
> - Driver
> Passes configuration to user agent if not already set and to renderers.
Right. Driver will probably still remain our top-level component,
serving as a black-box of the whole FOP-process.
> - All renderers (ie. Renderer, StructureHandler implements)
> This is so that the renderer can get its own specific information.
> The PDFRenderer could have font setup, stream filters etc.
Correct. That's something I'm burning to do for a long time. PSRenderer
will get very configurable eventually.
> - Configurable FOUserAgent (have default FOUserAgent that can be
> used/extended without config)
> To make it possible to setup all the various options like dpi.
I'm still at a lack of knowledge on these new things. :-( But it sounds
reasonable. I think a lot of thinking when using Avalon goes into which
classes are components (they get a logger, configuration etc. and
provide some sort of service) and which are merely data-holding classes
like an InlineArea. Correct me if I'm wrong: UserAgents are those
classes that do the heavy work that was formerly distributed in many
different classes directly on classes that change into simple
data-holding classes at the moment.
> The logkit Logger can be configured using this but it is not
> appropriate. If FOP is run from the command line then it should do what
> it already does and when embedding it would setup its own logger.
Logging is also something that is set on the child by its container. The
command-line wrapper sets a simple ConsoleLogger on the Driver by using
the LogEnabled interface.
Other containers like Cocoon will configure their Logging somewhere else
and set the desired Logger using LogEnabled on Driver, which in turn
passes some child logger of the given one to its children.
> The image cache and other cache are similar. These can be set with a
> static method and through the driver respectively.
I'd like to avoid the static stuff, if possible. There's the concept of
a ComponentManager (or after an evoluntionary step the ServiceManager),
which allows components to look up services provided by the
container/parent. There are multiple implementations in Avalon:
ExcaliburComponentManager (ECM), Fortress, Merlin, Phoenix. Using this
mechanism forces us to think again about some interfaces, or helps us to
easily provide multiple implementations of the same interface.
I can only say this: restructuring FOP to use this concept means some
work. We've done it for our applications and we love the result. I'm
sure Nicola Ken Barozzi can help here. I can help, too, I want to. I
just can't invest so much time as would be necessary at the moment. I'll
have 5 weeks off in August from which I intend to invest at least a week
into FOP. What I propose here is just my personal opinion and I can
understand if you, Keiron, don't want to be braked by having to dive too
much into Avalon. But I'm trying to help as much as possible. I'm
drowning in work but try heavily to get out of this.
There's not only cache components (for which Avalon Excalibur may
provide some helpful stuff), but also things such as an URI/URL-Resolver
(adopted by Excalibur from Cocoon) which may be an interesting feature
and may improve the integration with Cocoon. Actually, using Avalon
helps integration with Cocoon in a general sense. I'm also thinking
about creating a font facility which can manage fonts across renderers.
There may also be little components like a table column builder for
which different implementations are thinkable. We've had two different
approaches on line-breaking, right? I'm sure there are others.
I think, looking at Cocoon is inspiring. How they cleanly split up the
system into highly configurable and exchangeable parts. And it helps
killing those multi-threading problems (I hope).
There has been some discussions about configuration. There's always the
distinction between system configuration or component setup on one side
and calling parameters (ex. from the command line or from calling a
method on Driver) on the other. I've seen the latter having been handled
through Avalon's Context interface. Maybe this is not even necessary. I
think this may have to be investigated further. We can always ask the
Avalon guys who are eager to help when someone (especially an Apache
project) wants to adopt their patterns. I can be contact person. I'm
working with Avalon for about 9 months, but I'm not a specialist, yet.
Maybe Nicola Ken Barozzi also wants help out a bit. I think he offered
his help at one point.
So much from me at the moment. I hope I contributed some constructive
words and that you guys understand what I'm trying to tell. I know that
I'm not a pro in this regard.
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Tel. +41 41 317 2020 - Fax +41 41 317 2029
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]