From: "Joerg Pietschmann" <[EMAIL PROTECTED]>
> "Nicola Ken Barozzi" <[EMAIL PROTECTED]> wrote:
> > I've used Avalon framework in many projects, and IMHO it's not
heavyweight.
>
> Ok, scratch the heavyweight.
>
> In order to clarify issues: I have to use FOP in an environment
> which already provides logging, configuration management and life
> cycle management.
What is it?
> I don't want to look into another log file.
> I don't want to write more config files.
?
> (There is also the fact
> that said environment goes to great length to make augmenting
> already provided functionality as complicated as possible).
Avalon? I disagree. I've used it in a 10 months project. It saved me weeks
of work. And the architecture came out really clean.
> I have
> already customized ErrorListeners, URIResolvers and such and i
> want to reuse the functionality in the most straightforward way
> possible.
Using Avalon *is* reusing functionality.
> I don't want to write more customizations just for the
> Apache logkit. In particular, i don't want to learn how to write
> such customizations.
Customizations? I don't get you here.
> I don't want to prevent anyone from providing a FOP embedding
> using logkit and avalon.
Ok. Anyway, logging is a minor issue. If Avalon were logging, it would be
just logkit.
> I *want* however access to a core which
> doesn't rely on yet another toolkit for common functionality
Wait a second. If you need configuration, you *need* it. So you need to
write code to do it. So, what's the difference between importing Avalon code
or writing it yourself? What do you gain in writing it from scratch?
> and
> fits as seemlessy as possible into a run time environment roughly
> equivalent to the JDK 1.4 API (with emphasis on JAXP 1.1).
Sorry but I don't get you here. What is your measure of seamless?
I don't want this discussion to get into -just- logging, because IMO it's
not the point.
FOP (correct me if I'm wrong) is about transforming a fo tree in an area
tree, and then render this in many ways.
It's not about logging, configuration, lifecycle management, URI resolving,
etc.
But it needs them.
Avalon provides them, very well IMHO, and it's tried and tested code.
Why not use it?
My opinion is that using Avalon, FOP can concentrate on its core tasks, the
FO->AT->Render phases.
I would even dare go one step further.
FOP has basically two phases: FO2AT and AT2Rendering.
In Cocoon2, the first is a Transformation phase, the second a Serialization
phase. My crazy idea is that the new SAX driven FOP can be built on Cocoon
as a Transformer and a Serializer. All "utility" stuff is taken care of by
Cocoon. In this way we can concentrate on the *real* features of FOP. When
it works, we can then make it run in a more lightweight environment built on
Avalon.
For this, I seriously volunteer.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
