Vadim Gritsenko wrote: > >So the remaining question is, is fortress/merlin stable and usable? > >If these both points can be answered positiv, I would say: +1. > > > > -1 for 2.1. If you read this thread, you will see that the changes are > too drastic to make this in 2.1, and it already has loads of changes by > itself. This asks for at least 2.5, or even 3.0.
-1 for 2.1, no question about it. It is true that Cocoon needs a much better component containment technology for us to be able to implement cocoon blocks as designed so far. But you have my word that I'll continue to -1 any change to the 2.x family of Cocoon releases if some fundamental contract like marking interface to represent component behavior stop working. My suggestion to the current avalon developers that share Cocoon's concerns (not all of them do) is: think incrementally, think about migrations paths, think about small evolutionary steps. I know (by experience) that this is extremely hard to do (or take a huge amount of time and energy) but Cocoon *is* a stable technology and we want to continue it to be. We will not change some fundamental interfaces or contracts any time soon. Let me repeat this for those worried guys that are reading this thread: WE WILL NOT CHANGE FUNDAMENTAL CONTRACTS UNDER YOUR FEET Got it? Should I repeat it again? no? great. If a new component container doesn't allow my home-made avalon components to run as they did before, this new component container will not make it into Cocoon, unless an *easy* *well-documented* *simple* and *effective* migration solution is offered to the user (and to our cocoon developers as well). Sure, 15:1 performance ratio is killer, but how much of that performance improvement goes into our perceived performance when all our pipeline components are pooled and 80% of our average pipeline time is spent into xslt processing? Please, don't take me wrong: I'm the biggest fan of clean and well designed frameworks (after all, I'm the one who started Avalon, remember?), but as Avalon 4 took 4 years to become a reality, I'm all for waiting maybe even *years* before switching to anything new on this side. Yeah, I know that a new CM is not Avalon 5, but I'm fear the fact that with metacoding (that is: xdoclet-like behavioral metadata), the separation between the two becomes accademic (and it is, in fact, happening). So, Avalon 4 states clearly that component behavior is based on marking interfaces. Avalon 5 wants to deprecate these in favor of external metadata for a number of (admittedly good) reasons. The modern Avalon containers (fortress/merlin/phoenix) deprecate marking interfaces to define behavior. Hmmm, tell me: which version of Avalon are you guys implementing? Where is the line that separates "framework" from "implementations"? So, the real question should be: when should Cocoon use a component container based on the design principles of the next version of Avalon? Answer this. -- Stefano Mazzocchi <[EMAIL PROTECTED]> -------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
