I don't agree with you calling Ted Husted's ImageButtonBean crap - maybe more elegant solutions will come along, but it still doesn't mean this isn't a perfectly good workable solution to the image button problem.
http://www.husted.com/struts/tips/001.html Also I don't understand which "recent additions" you're talking about - ImageButtonBean was added to Struts two years ago according to the CVS log http://cvs.apache.org/viewcvs.cgi/jakarta-struts/src/share/org/apache/struts/util/ImageButtonBean.java Were there other "recent additions" that you had in mind other than ImageButtonBean? Niall ----- Original Message ----- From: "Michael McGrady" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Tuesday, September 21, 2004 3:40 PM Subject: Re: Struts Bloat: Framework > Rick Reumann wrote: > > > Michael McGrady wrote the following on 9/21/2004 9:37 AM: > > > >> What do you do with classes like DispatchAction and ImageButtonBean > >> (which solve the same problem in different ways) when someone comes > >> up with something better? > > > > > > You need to include some flavors of DispatchAction in the core of > > Struts and although I don't use Tiles (I use Sitemesh) and I no longer > > use DynaForms of any flavor, I think there is no problem including > > them. Now, if you included SiteMesh as 'part' of Struts that would be > > dumb since it is completely stand alone, but Tiles (from what I > > remember, relies on Struts, but I could be wrong there). > > > > Granted there is a fine line sometimes between bloat and necessary, > > but I only see major bloat when I'm 'required' to extend a bunch of > > classes that I don't really need. > > > > One of the nice things about Struts is it comes with a bunch of stuff > > to make your job easier. You don't have to go google around to find > > some Dispatch implementation or even for a solution for web layout or > > dynamic beans. (It doesn't mean you can't go find other solutions.) > > Having this stuff easily available is a huge plus especially for new > > developers. > > > > Under your philosophy Struts would end up being just one > > ActionServlet, a config file, a RequestProcessor, one Action and one > > ActionForm. Then you'd be on your own to find validation, web layout, > > dispatch, and tag solutions. > > > Hi, Rick, > > You are reading me too severly. I am seeing second class work being put > into the framework and it will be very hard to get out. It is not > helping users but is encouraging them to use Struts oafishly. I am not > saying this is rampant. I am saying that doing something about the > present tendancy to put crap code that is unrelated to the mission into > Struts should be addressed. > > I certainly think that the tags that are tied to forms are part of the > framework. I think there are distinctions here that are more finely put > than the present division you see in our discussion. > > I am all for people being assisted with using the framework. Why > wouldn't I be? The point is that Struts is getting to that point in its > maturity where it needs to carefully consider what additions are > worthwhile. The newer additions are quite suspicious. I think that > ImageButtonBean, which I advocated in the early stages of that problem, > is a rather shocking addition to the framework. When the canaries start > dying, then we need to look at these issues. We can wait until Struts > is full of crap like ImageButtonBean, or we can address the issues > early. That is my only point. When a framework is essentially done, > the real innovators will go off to other things and the remaining > caretakers can easily blotch the whole deal if they are not reminded of > the mission. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
