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
- 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
> 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

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]

Reply via email to