> 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): > org.apache.avalon.framework.configuration.Configuration > > 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 > example.
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. Cheers, Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern Tel. +41 41 317 2020 - Fax +41 41 317 2029 Internet http://www.outline.ch --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
