Well, I don't agree that the only way to not have Enabler interfaces is through Constructors. I personally think that
a) constructors are an ugly carryover from C/C+ B) using constructors to denote metadata like dependencies is a code smell I agree that you don't usually pass around managers, etc. via serialization. But how do you pass components that depend on managers if you can't re-wire dependencies after object creation? You, and Pico, assume that object creation and dependency usage will always occur in the same VM. This is not necessarily the case. But that's not even my biggest issue. This is just a consequence of b) above. Anyway, this is all Off Topic for WW... > -----Original Message----- > From: Ara Abrahamian [mailto:[EMAIL PROTECTED] > Sent: Friday, July 11, 2003 1:59 PM > To: [EMAIL PROTECTED] > Subject: RE: [OS-webwork] Decision: Xwork IoC > > > Jason, actually I think a constructor based solution is > better. I was probably the first one to tell my concerns > about this approach to Aslak and the serialization issues, > long before anyone heard of Pico. I'm using the IoC stuff in > an app and my own conclusion on this type 2/3 debate is that > type 3 is better. > > In real world scenarios the dependencies are not data or > javabeans, they are things like manager classes or services. > You pass data around with RMI or in a servlet container. You > don't serialize service objects. It's a design smell if you > do imho, or perhaps if you mix them much. > > There have been some discussions in pico-dev about supporting > constructor chaining. I think relying on a single constructor > but letting define a no arg one for the rare cases is a good idea. > > Ara. > > ------------------------------------------------------- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing & more. Download & eval WebKing and get a free book. www.parasoft.com/bulletproofapps1 _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
