Menu
▾
▴
Re: [Springframework-developer] Sad but true, was Another BeanFactory feature
|
From: Rob B. <rob...@ve...> - 2003-09-07 16:43:58
|
Last comment: A wise man once said: "A framework should be easy to use. Unduly complex frameworks will be ignored by developers, and create problems of their own. Irrelevant, or seldom-used, capabilities are a key danger. The Pareto Principle is particularly relevant to framework design. Often it's best to settle for a simple solution to most problems than a comprehensive, but complex solution that makes many tasks harder than they should be (J2EE arguably falls into the latter category)." Rod Johnson - Expert one-on-one J2EE Design and Development pg396 paragraph 5 I agree that many open source projects die because of "marketing" problems. I don't want that to happen to spring either, because I hope to use it in future projects of my own and want it to be a well supported framework with a thriving community. I'm perfectly fine with this feature being added to spring. I also don't want to seem the black sheep / black cloud, and I think that it appears I may have come off that way.. Please excuse me if that is the case. I only ask that the Pareto Principle be kept in mind when adding any "feature" only for the purposes of "marketing". It can also be considered a "feature" to not include capabilities that are "Irrelevent, or seldom-used" or that the project developers "don't really recommend". There are a few way to compete on the "marketing" front. We can all jump off the bridge because the PicoContainer does. We can all forget spring completely and use entity beans and struts because "everyone else does". Or we can say, no, we don't do xxx or yyy because doing things that way is bad. We do it this way instead because it's better. Let us show you how and why it's better. Again, I'm fine with this particular "feature". I just concerned it will be one of the first "features" to sneak in for marketing and then set a precendence. It's always harder to close the door once it's open. It's also harder to "remove" a feature because "no one" uses it. Someone, somewhere will use it, and then when it's removed complain like crazy. AS for the "global switch". My thoughts behind that were to offer some sort of "strict" capability, where any of the features that are not recommended can be shut off as a group. This would prevent a developer from inadvertantly using any feature (not just this one) that is not recommended. Kind of along the lines of the XHTML strict / transitional option. The same thing could probably be implemented by having two DTD's for Spring. One that has all the "added for marketing" stuff, and one that has only the recommended stuff. Doing things in this manner would require no code changes to Spring itself, and still have the advantage of preventing the use of "marketing" features accidentally by developers - as long as the developer verifies their XML against the DTD. If you feel it's not needed though, I'm cool with it. Later Rob > I understand some concerns about this feature. > > Rob, I don't think it needs to have a global switch to turn it off. It's off > by default. It's off if you don't know it's there or don't want to. The only > way to turn it on involves adding an optional attribute to each bean that > uses it. It's backward compatible. It doesn't complicate the API (no more > public methods on classes application developers will use). > > Secondly, if no one uses it and it ends up being only for marketing, I'll > happily get rid of it. I believe we should be ruthless with features no one > uses. Hibernate get this right. > > Marketing: I agree it's sad. But there are a lot of good open source > projects that don't go anywhere, meaning it doesn't matter how good they > are. I don't want Spring to be like that. I think our architecture is > particularly good, we have an advantage in my public profile and the fact > that many of us regularly contribute to TSS etc, but we need to consider > marketing. > > Nevertheless, I would never want to do anything that compromises our > architecture. I don't think this feature does. > > >While I'm sure most of us are very talented developers, > almost everyone I talk to always comments on the programmers who can't > figure out how to turn on a light switch. > > I used to think that. But I'm starting to wonder if we aren't all being a > bit naive here. Maybe it's just the market, but I've found that I can hire > good developers in London who are capable of working things out for > themselves. Of course I have to interview 2-3 others before I employ one, > but there are a lot of good Java developers out there. > > Regards, > Rod > > > ----- Original Message ----- > From: "Trevor Cook" <pr...@se...> > To: <spr...@li...> > Sent: Friday, September 05, 2003 9:20 PM > Subject: RE: [Springframework-developer] Sad but true, was Another > BeanFactory feature > > > 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 developers, > 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 care > of (like the "automagical wiring"). I also see broad acceptance of Spring > being of big value, since that provides more use/testing in the real world, > 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 with > the time/experience to fully understand how to use/configure Spring are in > 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 doind > an important, enterprise level system, I definately want to control exactly > what's going on, and I will probably have a more complex context. However, > 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 to > be concerned as much with marketing these days as commercial software. It's > just sad to have it be so true, since many open source projects are attempts > 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 "automagical" > 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 stuff > 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. Also > "autowiring", etc would be disabled. This (I think) would make both crowds > happy because those who want automagical stuff can use it, they would just > specifically have to turn it ON for the framework before using the > automagical features in code / config files. Those who don't can leave it > 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é : jeudi 4 septembre 2003 23:42 > À : 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 > > > > ------------------------------------------------------- > 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 |
