cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianugo Rabellino <gian...@apache.org>
Subject Re: [RT] Simplifying component handling
Date Tue, 03 Jan 2006 09:12:18 GMT
On 1/3/06, Upayavira <uv@odoko.co.uk> wrote:
> Reinhard Poetz wrote:
> > --- Carsten Ziegeler <cziegeler@apache.org> schrieb:
> >>Gianugo Rabellino wrote:
> >>
> >>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.

> >>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%
> >>compatibility.
> >
> > 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.

It's not so easy. First let me state that I don't have any particular
blocker if all we're talking about is adding constructor injection to
ECM++: whatever goes in the direction of a lighter and
less-Avalon-dependant Cocoon gets my applause. I do have issues,
though, when mixing models. something we're very good at. Keeping both
interface injection and constructor-injection (well, why not setter
injection as well at this point, shouldn't be too hard and, hey, gives
one more choice) and telling users to "take their pick" isn't going to
work: adding features blindly not because of architectural/design
issues but because it's tiresome to add 5 lines of code and - at the
same time - not considering how users might be confused by the fact
that we're still using Avalon but we're subverting its very principles
is just not going to work.

Careful also about taking multiple paths (and again, this isn't quite
the case of this constructor-injection stuff which gets my +0 as in
it's not my favourite solution but I'm fine with it): removing cruft
later on is hard, and the situation we are in how should prove it:
once you've baked a cake, there is no way to get your flour, butter
and eggs back to bake another one.

Ciao,

--
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance: http://www.orixo.com
(blogging at http://www.rabellino.it/blog/)

Mime
View raw message