cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: [RT] Some notes about the "Real Blocks" issue
Date Thu, 14 Oct 2004 02:20:30 GMT
On Thursday 14 October 2004 05:23, Vadim Gritsenko wrote:

>   * Why new type of container is needed;
>     (I suppose: because some things are broken)
>   * What's broken in ECM;
>   * Why it can't be fixed in Fortress;
>   * Why Avalon compatibility can't be achived with new
>     container (so that you need second one in parallel).

An interesting thought that I have asked myself.

Looking at the 'container situation' today in Cocoon at the greatest detail, 
and one should soon realize that the "Pojo haven" is a bit misleading.

Let me elaborate;
Assume for a second that the Avalon Lifecycle contract was called the Cocoon 
Lifecycle contract and had no life outside of the Cocoon world. That contract 
specifies how the components are born, managed and killed within Cocoon.
Cocoon also has its own Configuration system and component declaration system.
Furthermore, there is something one could call a Request Cycle contract, the 
sitemap processing interfaces and the various XML chaining interfaces.

IMHO, the situation of component operations are far more complex than "Pojo 
will save the day". And that is probably the main reason why the Fortress 
effort 'stalled' ; Cocoon is so much more than dependency+conf injection. And 
I think the Spring/Pico camp is probably fooling themselves thinking 
otherwise. A Cocoon Pojo will not be easier to use outside the Cocoon 
environment than today's set of components are, since there are so many other 
things that needs to happen.

IMHO, why not simply fork the ECM into Cocoon and mold it to the needs here? 
Add CDI and Setter injection into it, if people feel that is needed. 
That would allow for a much smoother path for the majority of users. And as 
Stefano kindly explained to me...

Second principle of thermodynamics;
Entropy of a system increases when the transformation is not reversible.

i.e. evolutionary steps of ECM are reversible, a leap-of-faith is not.


Cheers
Niclas
-- 
   +------//-------------------+
  / http://www.bali.ac        /
 / http://niclas.hedhman.org / 
+------//-------------------+


Mime
View raw message