Tuncay Baskan wrote:
On Mon, 20 Sep 2004 20:30:46 -0400, Rick Reumann <[EMAIL PROTECTED]> 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).
--
Rick
I *strongly* agree with Rick on DispatchAction.. Especially from the "new developer"s perspective, Rick's words are quite right. org.apache.struts.actions package contains only a handul of classes which are *required* in my opinion.
I think the only package can be considered as bloat is the tiles package. It should not be in the default package, it can stand on its own and there are many alternatives. Also, from the number of messages about tiles in this list, I think it brings more problems than it solves. I have to say that I only tried it once and hated.
/tb.
Thanks, Tuncay,
Not sure which point you strongly agree on, but it seems like the one that said, in essence, there is not /too much/ bloat. The problem is not size but function. I use Tiles and love it but agree that it should be in a separate offering. 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? If you improve ActionMapping, then ActionMapping stays. But, classes like DispatchAction and ImageButtonBean, which are quickly outdated by imaginative coding of users of the framework, remain as useless relics which you cannot easily jettison because taking them out will break legacy code. What was surprising to me is that ImageButtonBean went in at a time when better solutions were on the Struts Wiki. That is very poor management.
I do see the point, of course, that new users need to have an easily accessible place to get good examples of patterns that work well with Struts. Putting the patterns in Struts, however, seems to me to be thick-headed.
Michael McGrady
