On 13.08.2002 23:15:39 J.Pietschmann wrote: > Jeremias Maerki <[EMAIL PROTECTED]> wrote: > > The FO objects are primarily just data holder, so it doesn't make > > sense to make them too heavy-weight. They need to be as light-weighted > > as possible to save memory. Most of the logic is transferred to the > > layout managers. And the layout managers are components/services. They > > will eventually conform to the Avalon lifecycle. > > Well, I'm not a real Avalon guru (and actually not the > greatest of the Avalon fans, after several dozen hours > of stepping through Excalibur stuff in a Cocoon > application).
I'm no Avalon guru, either, but I'm a big fan. We use it at work with great success and I would never consider throwing that out again. > Therefore I need some explanations (read past > the questions first): > - What's the advantage of transferring functionality of > managing layout from the FO objects to layout managers? > I understand there need objects managing layout of pages > and lines, which do not have a FO counterpart, but for > the other stuff? Keiron answered this already. I'd just like to add that in this approach information holding and layout logic get separated which leads to a cleaner design. > - If the FO objects are primarily data holders, why > have them at all, instead of using a standard DOM? See Keiron's answer. And I think that a DOM would be too generic making the code hard to read. The FO objects can be optimized to their tasks. > - What's the advantage of layout managers being Avalon > components? Let me explain that by showing what an Avalon container does for you: - You can define a configuration for a component to fine-tune its behaviour. - It provides factory services which can be configured. That means you can have multiple implementations of the same interface and define in configuration which one to instantiate at runtime. We've already had such a case for line-breaking, I think, where Keiron and Karen both had an implementation. We could, for example, have specialized implementations for languages such as Japanese, if that makes sense. The implementations could be looked up based on the language property making the code itself clearer. - It provides pooling services. Layout managers (or renderers etc.) could be reused instead of recreated. If it can be used in a multithreaded way, even better. Sure, you could have that without Avalon, but you would have to write a lot of code just to provides this functionality. You'd have to debug, to maintain. > My understanding is that a component framework, and in > particular Avalon, provides mechanisms for conveniently > configuring and composing objects as well as some often > used services like logging, therefore boosting developer > productivity. Correct. That's what it does. > In order to sell it to *users* of the > developed software, the framework should provide something > for them as well, like caching and saving configuration > and composition overhead by recycling objects, rather > than only having a hefty ressource usage tag attached. Avalon CAN do that. > In order to get the latter, the objects both have to be > a bit cooperative and have to be either being a > composite or part of a composition, or have some > significant configuration data. > You know, on the Cocoon mailing list there are now and > then complaints about "over-Avalonization", which means > using Avalon for objects too small or too specialized so > that only the developer gets a benefit (however small), > while the user gets the overhead. I got a bit of that following the Avalon mailing lists. I think this may have happened, because the devs there were/are in the process of learning how to work with Avalon. The Avalon guys are also still learning. From following the mailing list I think at least the Avalon devs have identified this problem and they are constantly trying to improve documentation to communicate what they have learned. I don't intend to over-avalonize FOP. As I said before it doesn't make sense to spread Avalon in to every corner of FOP (the FO tree for example). The most important thing is to identify the real components. Maybe they overdid it at Cocoon. I can't tell. What I intend with Avalon is to improve code reuse (factory services, pooling/recycling, caching, URI resolving, resource loading etc. exist in Avalon) and to help improving overall design by promoting SoC and IoC. There are other benefits but also the fact that Avalon has a relatively steep learning curve. Well, nowadays even the Jakarta Commons people don't all simply say no to Avalon. The problem I have is the fact that currently I cannot dedicate enough time to do the full transition to Avalon. And I'm essentially alone at the moment. Nicola Ken Barozzi has once offered his assistance but he seems to be too involved in too many projects. So I concentrate only on slowly trying to show a way towards adoption of Avalon which I started with looking over logging which in turn is the first step in the Avalon life-cycle. That's also what we did at work when we rewrote our system based on Avalon. When I'm back from holidays I will again try to get the resources to work on FOP but I can't tell what's going to happen. > If I'd be asked for components in FOP, I'd start with > the components FOP provides to the external world. A > good starting point would be the FOP CLI, which can be > easily seen as a composition of an XML parser, an > optional XSLT processor, a FOP core layout component > and a renderer, with the latter two provided by the FOP > team. What else components do we have to export? I don't think CLI is a good starting point because it's just a little wrapper around the high-level API for FOP. By the way, I should really reread the API discussion we started two months ago. Anyway, from the outside I'd like to view FOP as a simple transformer/morpher. The renderer should, for example, be an internal thing that may, of course, be configured, but should not be visible to the outside. FOP is essentially: input --> transform/morph --> output where input and output are just parameters to a call to FOPs processor. From the outside you shouldn't have to care whether FOP uses an AT renderer or a structure renderer. And I think this processor/transformer/morpher is the only component that should normally be exported. > The other approach is bottom-up: Which common, at least > potentially reusable services (or components) do FOP > components use? Immediately come to mind: > - Logging and XML parsing of course. > - Sources for external graphics, including customisable > resolvers. > - Fonts: getting metrics and character mappings for the > layout core, perhaps more for renderers. > - Components implementing inline-foreign-objects :-) Yes, and: - Temporary storage facilities (for pages with forward references, for the AWT viewer, for renderers that will write the header of the output file at the end of rendering etc.) - Image loading - Caching of images - line-breaking algorithms, perhaps There may be more. I'm going to document this once I get to the point where I really have the full overview. > Again, what else obvious components do we use? I'd like > to add stuff like PDF encryption, but I don't know enough > about this to decide how tight this has to be integrated > into the PDF renderer. No, I think it is an agreement that the PDF library should become a fully detachable part of FOP. PDF encryption will likely be done in the PDF package and not in the renderer. The renderer should only use the PDF library. I'm not so sure if the PDF library is really a component, because it mostly consists of data holding classes. But maybe it needs to be refactored a bit to separate logic from data holding like for the FO tree. As an aside: Quite often libraries such as a PDF library is avalonized by creating a little wrapper around it. This was done with Tomcat for example. The wrapper is then only a well-defined entry point to the enclosed library/component/package. > Answers and Comments? I answered as well as I could. I hope it helps a bit. Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
