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 Fri, 30 Dec 2005 20:15:05 GMT
On 12/30/05, Giacomo Pati <giacomo@apache.org> wrote:
> On Fri, 30 Dec 2005, Vadim Gritsenko wrote:
> > Carsten Ziegeler wrote:
> >>  Gianugo Rabellino wrote:
> >> >  I'm definitely not a fan of constructor injection, exp. when we
> >> >  consider how (way too) often we resorted to inheritance in Cocoon
> >> >  components. Now, while interface injection is clearly out of fashion,
> >> >  sticking with Avalon/Excalibur also means that it would be difficult
> >> >  to get around the container (e.g., how do you release components with
> >> >  your approach? I assume Excalibur still kinda needs that).
> >>
> >>  Yes, Excalibur still needs it - but it's easy. Bascially, you "emulate"
> >>  the service() method on construction of the object and then you
> >>  "emulate" the dispose method when destroying the object. Everything our
> >>  ecm++ needs to know is there. As I said, I've done this in Fortress and
> >>  we can use that code in ecm++ as well.
> >>  And we could implement setter injection with some kind of auto wiring as
> >>  well. It's not really that harder. But using setters again requires to
> >>  code more than using a constructor.
> >
> > I'm with Gianugo on this one - I'd better have setter injection instead of
> > constructor injection.
>
> Actually the problem I see with setter injection is that you normally
> will open up the setter method (make it public) to your
> configurator/instatiator and thus to everybody else.

I guess we could waste a near to infinite number of electrons debating
the various IoC types and their downsides, so I won't delve any
further on this (apart from +1ing Vadim's reply to your concerns, exp.
the part about final members). My point is actually a tad different:
like it or not, we are still working with Avalon which is
interface-injection based: bastardizing the model with some clever
hacks won't get us anywhere and will just confuse people. Now, if we
were to completely change the approach, this discussion might have
much more sense, but arguing about it while sticking with Avalon is
moot, IMHO.

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