cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira>
Subject Re: [RT] Simplifying component handling
Date Tue, 03 Jan 2006 07:43:00 GMT
Reinhard Poetz wrote:
> --- Carsten Ziegeler <> schrieb:
>>Gianugo Rabellino wrote:
>>>On 1/2/06, Ralph Goers
>><> wrote:
>>>>That seems to be a catch-22.  How do you move away
>>from Avalon without
>>>>making these kind of changes?
>>Good question - I think noone is able to answer that
>>>Honestly, I don't see how anything in the 2.x
>>series could move away
>>>from Avalon. Too much refactoring needed, too many
>>issues on the
>>Yeah, and I really don't understand this - I (and
>>others) propose small
>>but simple steps to a) improve using Cocoon and b)
>>provide a smooth
>>migration path. But even if these proposals do not
>>include heavy
>>refactoring and do not come with problems, people
>>are blocking it and
>>always point to the "we need a rewrite". Then if
>>people are suggestion,
>>let's rewrite, the same people (and others) complain
>>that that is
>>currently not an option. So in the end we are
>>So I'm coming back to my idea, is anyone against
>>adding constructor
>>injection to ECM++ or at least make it pluggable so
>>I can add it for my
>>own projects? The change adds only a feature while
>>maintaining 100%
> Without having time to understand in depth what you
> guys are talking about, I'd say that we should not
> block any features that don't introduce any backwards
> incompatibilities. If people disagree here, I would be
> very intersted in their reasons ...
> So +1 for your enhancements Carsten!

Even more - Gianugo makes some valid points about the future. However,
at this point, we cannot prove that his opinion is correct. So in my
view, we should be taking multiple paths until one shows up to be the
clear winner. So, I'd say, Carsten, get on with improving 2.2 to address
the issues people have mentioned, and others, get on with prototyping a
new implementation of Cocoon. If/when that new implementation comes
along, we can see if it can be redone as a refactoring rather than a
rewrite. Until then, let's move on on all fronts. We stand a better
chance of winning that way.


Upayavira, who's been away for a few days and hasn't read the full thread

View raw message