Struts Bloat: Framework

[Michael McGrady <mi...@michaelmcgrady.com>]

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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Struts Bloat: Framework

[Michael McGrady <mi...@michaelmcgrady.com>]

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 two(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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Struts Bloat: Framework

[Rick Reumann <r...@reumann.net>]

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 two(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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org