Rick Reumann wrote:
Michael McGrady wrote the following on 9/20/2004 7:52 PM:
I have a real concern that Struts is going to continue to be bloated with what are not Struts, not part of the framework, but what are instead really very useful uses of Struts. DispatchAction and its progeny are just one example of this.
I would disagree with some of this. Since a DispatchAction can't really stand on its own (unlike the commons packages do) I really think it belongs part of Struts. I don't see any reason not to give people the options from within the framework (I no longer like to use DynaForms but I'm not really opposed to them being an option). On top of this, if I was new developer I would be quite frustrated if I had to go find a ton of optional packages just to accomplish some common/useful things. I actually don't really find Struts that bloated. The jar isn't that big, so I'm confused what the concern is? What is it that you find being introduced that is currently bloating struts? Over the past 2(maybe more?) years there haven't even been that many 'major' changes to Struts (a nice bunch of improvements but no major bloat that I can see).
I don't know if you really wanted a reply on this, Rick, but my reasoning is as follows. Things like ImageButtonBean are merely one solution within the Struts framework to a problem. There is nothing about ImageButtonBean that is tied in any way to Struts. Since DispatchAction extends Action, it is tied to Struts. This is true of all subclasses that use the Action base class. Once these patterned solutions are in the framework, I think they give the impression that they /are /in the framework. But, they aren't. They are just uses of the framework, some more clever and more elegantly considered than others.
Michael McGrady
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
