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). 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?
- If the FO objects are primarily data holders, why
have them at all, instead of using a standard DOM?
- What's the advantage of layout managers being Avalon
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. 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.
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.
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?
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
- Fonts: getting metrics and character mappings for the
layout core, perhaps more for renderers.
- Components implementing inline-foreign-objects :-)
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.
Answers and Comments?
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]