Stephen McConnell wrote:
The million little details that cocoon assumes on top of ECM is also the thing that scares me the most.
Me, too. And I'm really wondering if we can keep our nice little additions if we move away from ECM.
You may be able to, but they will be done differently. For instance, Merlin and Fortress use the Lifecycle Extensions API which can be used for most of the special things you are doing.
Is there someone who provide the breakdown of what Cocoon is doing over and above ECM? However things roll out - one of the biggest obsticles I see is that we need to move away from ECM/Fortress extension and to a solution where Cocoon does not need to access container APIs. With that information the Avalon crowd can address how to addres these requirements in a way that makes the concern indpendent of the container implementaiton.
We extend the ECM with our CocoonComponentManager, you can have a look at that class. All the features (hacks?) in there have to be somehow available using fortress, merlin or whatever. We have another lifecycle type, the request lifecycle component. This is an extension to poolable and means that per request only one instance of this component is used. So if two other components lookup this request lifecycle component, they get the same instance. The implementation of this extension is a little bit difficult as we have sub requests that run in the same thread but have a different set of request lifecycle components. In addition it's possible to process on request multi threaded which makes this even more difficult.
You might be able to get around this with a PerThread model, as I am not aware of any Java Servlet container that shares the same thread between multiple requests.
We will have to look at what options are available to implement this.
There are some other important extensions like the environment handling for the source resolver and the sitemap configurable components. They use more or less the same technique used for the request lifecycle components.
Right.
I'm more and more thinking that we should do one thing after the other: first creating our blocks and than moving to fortress or merlin. Or the other way round, if someone things that it makes more sense. But we should avoid doing both at the same time. I mean, we are currently happy with ECM - it works, it's stable and the only real concern we have is the big cocoon.xconf which is solved with blocks anyway. (I don't want to say that fortress/merlin are not stable with this).
ECM is ok when you already have an infrastructure built with it. However, maintaining the roles file and the component source code can let things get out of sync--esp. if you are refactoring. Fortress and Merlin will allow you to change EVERYTHING about the implementated component--including the package it resides in--without requiring changes anywhere else. Try that with ECM.
It opens up the doors to refactoring a bit wider.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin