|
From: Rod J. <rod...@in...> - 2003-09-03 23:47:41
|
I've committed dependency check support to CVS. I think it's useful to avoid the need to write code to check that a certain field is non-null. I've done this once or twice in init methods. Of course where there are defaults it fails. I guess I could have added a check that the field wasn't null...Maybe that would be a good modification? That would work with default values. Thomas, I've updated the DTD. Can you please put the latest version on the web site? I've also constrained the legal values of the "singleton" attribute to "true" or "false". Regards, Rod ----- Original Message ----- From: "Alef Arendsen (JTeam)" <al...@jt...> To: <rod...@in...>; "'springframework-developer'" <spr...@li...> Cc: "'springframework-developer'" <spr...@li...> Sent: Wednesday, September 03, 2003 8:17 PM Subject: RE: [Springframework-developer] Dependency checking > +1 > > I think this could be pretty useful (especially for colaborators), and I > definitely see the marketing value... > > Alef > > -----Oorspronkelijk bericht----- > Van: spr...@li... > [mailto:spr...@li...] Namens > rod...@in... > Verzonden: Wednesday, September 03, 2003 3:37 PM > Aan: springframework-developer > CC: springframework-developer > Onderwerp: Re: [Springframework-developer] Dependency checking > > > All, > > As I can see it the only arguable advantage that > PicoContainer has over Spring is that it can satisfy all > dependencies before allowing an object to be invoked, so that > an object can never be used when incompletely configured. I > don't like their constructor way of doing this, and I think > that it often makes sense to have optional properties, with > sensible default. So I've never been worried by this in > Spring. > > However, it's pretty easy to add optional dependency > checking. I've successfully prototyped the following, which > required very minor changes: > - add a new DTD attribute for the "bean" element called > dependencyCheck > - if this is set to true, XmlBeanFactory checks that all > properties on that bean have been set. If not it throws an > UnsatisfiedDependencyException. We can't do the PicoContainer- style > automatic wiring up as we can support multiple objects > of any type. They can only accomplish this because they > support only a single object of each type, which doesn't > satisfy the kind of real-world requirements I've used Spring > in. > > At present my prototype checks only Object properties > (presumably other beans in the factory). It might be good to > have three values for dependencyCheck: "no" > (default), "object" (collaborators) and "all" (primitives and > collaborators). > > As this is backward compatible and easy to do I'm inclined to > add it, if only for marketing value. There may be real value > in that it means that an init method wouldn't need to check > that a certain property was non-null. > > What do you think? Is this worthwhile? > > Regards, > Rod > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |