Menu
▾
▴
RE: [Springframework-developer] Sad but true, was Another BeanFactory feature
|
From: Trevor C. <pr...@se...> - 2003-09-05 20:20:47
|
I think it's a great idea, partly for marketing but more for an easier "entry-level" use. While I'm sure most of us are very talented developer= s, almost everyone I talk to always comments on the programmers who can't figure out how to turn on a light switch. Making Spring easier for those who don't have the time or expertise to figure out the details of the framework are more likely to adopt if most of the little stuff is taken c= are of (like the "automagical wiring"). I also see broad acceptance of Sprin= g being of big value, since that provides more use/testing in the real worl= d, and because a larger market of users will naturally draw more developers, thus improving Spring even more. With that in mind, I personally wouldn't mind seeing auto-wiring ON by default. I would not use it, and (I'm assuming) most of the developers I= 've talked to from the Spring project wouldn't use it. However, if those wit= h the time/experience to fully understand how to use/configure Spring are i= n the minority (which I expect they will be if we have a large user base), wouldn't it make more sense to have the defaults at a "beginner" level to handle the 80% of users, rather than "advanced" to support the 20% (which then forces the 80% to do more digging/searching, and often going elsewhere). I also wouldn't say I wouldn't recommend using the autowiring. If I'm do= ind an important, enterprise level system, I definately want to control exact= ly what's going on, and I will probably have a more complex context. Howeve= r, for all the "one-off" standalone apps, internal web sites, and prototypes= , you simply don't need to manually code stuff, and even the "advanced" developer might use the auto-wiring. +1 to adding it with either default setting (but I'd lean to "beginner" defaults) T -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Rob Butler Sent: September 5, 2003 12:30 PM To: Jean-Pierre; 'Rod Johnson'; 'Ivan Ristic' Cc: spr...@li... Subject: [Springframework-developer] Sad but true, was Another BeanFactory feature Sad but true (Metallica) It's pretty sad when an open source, well architected project has to add features that are of little use or ones that they "don't really recommend= " for "marketing" value. I know it's true that open source projects need t= o be concerned as much with marketing these days as commercial software. I= t's just sad to have it be so true, since many open source projects are attem= pts to get away from the marketing and hype and deliver a quality (free) technically superior piece software. Back to the matter at hand, I can see the value in having the "automagica= l" wiring, and I can also see the value in not having the automagical stuff. How about adding a feature to the framework that ALL the automagical stuf= f can be declaritively turned on/off(disabled) with just one setting, by default it is off(disabled). In that way, any attempt to use the automagical features in the config files throws an error on startup. Als= o "autowiring", etc would be disabled. This (I think) would make both crow= ds happy because those who want automagical stuff can use it, they would jus= t specifically have to turn it ON for the framework before using the automagical features in code / config files. Those who don't can leave i= t turned off. Later Rob +1 I agree it's not really to recommend. But marketing has to be taken in account. Jean-Pierre -----Message d'origine----- De : spr...@li... [mailto:spr...@li...] De la part de Rod Johnson Envoy=E9 : jeudi 4 septembre 2003 23:42 =C0 : Ivan Ristic Cc : spr...@li... Objet : Re: [Springframework-developer] Another BeanFactory feature > In a way, wiring the beans manually is a form of documentation > how system works. So, if it were up to me I would cancel all > automagical processes. Besides, we will probably soon have GUI > tools to configure our beans with and that will be more fun > anyway. I'm inclined to agree. But I think the marketing advantage is real, as the "objects cannot be in an inconsistent state" argument is the only thing PicoContainer can really claim as an advantage over Spring. Even if we don't use it, and don't really recommend it, this neutralizes that claim. ------------------------------------------------------- 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 ------------------------------------------------------- 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 |
