There are some things that I certainly agree with michael on and this
is one of them.
I think ( and i'm not alone in thinking this ) that struts needs a complete
overhaul.
At present the only reason I use it is because all the existing tooling
supports it.
eg m7 nitrox, WSAD, MyEclipse etc etc etc
If the spring tooling was as mature as this I would use it instead.
The project has a reputation for inflexibility, complexity and a lot of
unnecessary inheritance.
These are all hangovers from EJB with it's multiple interfaces and
fixed inheritance approach with the associated difficulties of testing,
slow development cycle etc.
Struts has done a superb job in the past otherwise it wouldn't be
so popular and there is a fantastic pool of talent in the struts
development team but it does seem like you are loosing mind-share.
If this were not the case there wouldn't be so many copy cat
web MVC frameworks springing up.
Perhaps it is time for an overhaul of struts. Rather than moving
your codebase to subversion perhaps you should leave your 1.*
development on CVS and start a completely new attempt for your
2.* series on a fresh server.
I do think that struts is a great product and I am a big fan of it's tag
libs and the MVC approach in general but I do think that it may
be time for a rethink
Everything is going POJO, attributes are the way forward. 1.5 will
mean that collections are no longer unknown bundles of objects.
A lot of people also want AOP features like declaritive behaviour
and easier testing.
People also want things to be more flexible and have shorter development
cycles.
I've been a developer for 6 years now. Programmed in about 5 languages
and still I find the slowest part of the development cycle is handling the
presentation layer with it's multiple reloads etc.
I mean i could write a desktop application now with remoting to do the
same job quicker than i could write the web interface.
That doesn't seem to be the promise offered when people first started
developing web applications. And I remember that far back.
One thing that I am certainly not suggesting and I want to make this
clear is that I am not suggesting that anyone fork the codebase.
There is certainly too much clutter surrounding the project at present.
It's better if you make it easier to do the difficult stuff rather than vice
versa and having everything but the kitchen sink thrown in there doesn't
make it any easier.
--b
approach
On Mon, 20 Sep 2004 06:31:24 -0700, Michael McGrady
[EMAIL PROTECTED] wrote:
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]
