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]
