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]

Reply via email to