Please do not cross post to both lists. Most of us on dev are also on user. If I choose to reply or ignore you on dev, I'll do the same on user.
Thanks. -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx ----- Original Message ----- From: "Michael McGrady" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Monday, September 20, 2004 7:52 PM Subject: Struts Bloat: Framework > I have raised an issue on struts-dev which I think impacts struts-user > as well. So, here is a cross posting, which under these cirucmstancs > makes sense, I think. > > Looking over Struts 1.2, I see that my ImageButtonBean, an idea > discarded for improvements some time ago, made it into the Struts > framework. This re-ignites my thoughts placed into another context and > which I think are worth putting under a heading which might engender > some response. So, here is a last try to get people to address the > question. If we continue to put mere uses into the framework, things > will get even odder. ImageButtonBean had little testing and was but a > germ of an idea. It spread quickly because the problem was pressing to > people. But, that does not make it a good solution. In fact, it is a > fairly poor solution. Discussions with people on the Struts user list > led to definite improvements. In those discussions, people shared some > of their ideas which are better than this. ImageTagUtil was a far > better solution for that problem in almost every respect. But, now > ImageButtonBean is in the framework and will have to be their for > sometime. That is not good, in my opinion. > > Open source and painting are connected in someways. The biggest mistake > of the amateur painter is to keep adding colors when the painting is > done. The result is always that murky, dark, ugly, look. Likewise, open > source, filled with people with egos, sometimes does not know when > something is done, finished, damed good and certainly good enough. > > 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 suggest that such > offerings would better be managed in a separate application called > something like "Struts Patterns" or "Struts Best Practices". Perhaps > such classes could be released as classes and either maintained (or > preferrably not) independent of Struts? > > I would hope that by the term "bloat" I don't convey that such classes > are not wonderful ideas and their authors are stellar citizens. It just > seems to me that a framework ought to be maintained as a FRAMEWORK and > that allowing USES OF THE FRAMEWORK to become part of the framework is a > groundwater mistake. Generally, I think it might be better if the > actions package were distributed outside Struts proper. > > As a framework, there comes a time when something like Struts is done, > and we need to move on to other things except diligent maintainence and > creating clever uses. My present predeliction is to save what presently > exists, clean it up by jettisoned what is not needed, and to watch for > good ideas that might arise in uses. This is just a thought. > > There needs to be, I think, a clear separation of Struts patterns or > clever uses of Struts and Struts itself. I would suggest that something > formal be instituted. Thanks for your ears/eyes on this. > > Michael McGrady > > > --------------------------------------------------------------------- > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]