avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Uli Mayring <u...@denic.de>
Subject Re: Integrating Cocoon (was: Access to Application ClassLoader from a Block?)
Date Sun, 25 Nov 2001 14:32:06 GMT
On Sun, 25 Nov 2001, Paul Hammant wrote:

> Not answering your question (Pete has), but when you've finished can you 
> publish the code back to us?  We plan, sooner or later, to make a block 
> that publishes Cocoon services internally and this sounds very 
> close.........

I was planning something like that for a long time, too. When I asked on
cocoon-dev about the way to go the relevant people said that I should 
take care to not violate IoC and to not deconstruct Cocoon in a way that
would make it unrecognizable as a project of its own.

The majority of people, who spoke out on this issue, thought that I should
not call a Cocoon component from my other components, but that I should 
have Cocoon call my other components. This is to preserve IoC, a
"Cocoon block" would violate it, as it can be called from outside.

That would mean that I should not bypass, for example, the Sitemap to
access "inner services" directly. There should be only one entry-point
into a Cocoon component and it should, if possible, be the same one as in
a standard download of Cocoon. If we accept this as a given, then the
follow-up argument "have Cocoon call your other components" sounds
inevitable to me.

When I say "Cocoon" in this context I do not mean the current Cocoon, but
the Cocoon that will remain after the on-going integration of several of
its components into Avalon. When that work is done, the whole issue might
present itself very differently.

The original poster apparently thinks of integrating the current Cocoon
into Avalon - something which may have no future in the light of the
on-going migration of components from Cocoon to Avalon.

I have meanwhile started along a different path. The whole IoC argument as
I tried to represent it above, didn't fit well with our currently existing
applications, which are all running under Phoenix. So I've written "my own
stripped-down version of Cocoon", something I called an "XML-Block". It
currently does XSL(T|FO) and can render to all the output formats fop
supports (it uses fop, xerces and xalan internally). This is of course
just a small part of what Cocoon does, but for me it's better to start 
small and work my way up, instead of the other way round.

That means I'm not using any of Cocoon's code, I think it would be too
difficult to keep it synched with the Cocoon project, unless there was a
broad agreement on philosophy, IoC or otherwise. The beauty of OpenSource
is that I can do my own thing and nobody has to agree with me and I have
to agree with nobody :-)



Ulrich Mayring
DENIC eG, Softwareentwicklung

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message