On Wed, 2002-05-29 at 17:18, Jeremias Maerki wrote: > > - 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.
That is essentially it. The FOUserAgent holds a bunch of decision making values that people may want to change. > > 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 see what you mean. Maybe this could do with a bit more thought. I was thinking that there are two scenarios, the common cache for all images and the context cache for instances of rendering. With a situation such as cocoon we could have a third based on the cocoon context and this may be more easily handled within the component manager. Everything else should remain the same I think. > 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. Any help is much appreciated. I just want to get the ball rolling with the intentions. We should be able to tackle this in parts. Keiron. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
