Cool, thanks Craig. It might amaze you to hear that not a single one of
those items I really disagree with :)
I was in the middle of composing a big, grandious new message, but I
think I can ask a single question here that really sums up all that I
was writing there...
Of this list, I don't see a single thing that can't be done in current
Struts. Admittedly some are not as easy as others, but none of it, as
far as I can tell, is undoable. So, the question is, why don't we? Not
you specifically Craig, I know your off on your own crusade :) Just a
general question for everyone else.
Over the past few months there have been a number of people who have
attempted to evolve Struts to "catch up" in some ways with what other
frameworks are doing. They have been turned away, sometimes for
obviously legitimate reasons, sometimes for more debatable ones.
Everyone seems to want to go off and create something entirely new when
I haven't seen a single good, concrete reason why Struts as it exists
today can't be evolved. Why?
Many of the things that people claim to want in a modern framework I
have either myself done or seen done with the current Struts codebase.
Things like components that remember and render their own state ala JSF,
a simple managed bean facility (IoC), built-in AJAX support, something
akin to a prerender facility, the work of Michael Jouravlev, all of
these things have been done in Struts, so clearly it is not a case of
Struts not being expandable or "fixable". Why is there so much seeming
resistance to doing this I wonder?
Frank
Craig McClanahan wrote:
On 9/10/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
Craig McClanahan wrote:
I hope you'll find my comments useful in furthering this kind of
discussion.
But I'm starting from a different place than you ... I personally think
it
is a waste of time to improve the tools and documentation support for a
five
year old architecture that is definitely showing its age.
Craig, I've heard you make this statement a couple of times... can you
go into some detail on where and how Struts is "showing its age"?
Here's a couple of things that (had we known then what we know now) would
very likely be different -- and areas where I think improvements would be
helpful:
* Actions as stateless singletons, instead of per-request instances
* Form beans (should have done it the way WebWork does)
* Extensibility of request processor (getting fixed in 1.3)
* Action chaining is messed up.
* Decorating actions (a la Spring MVC or WebWork or Tapestry) is missing
* Expression language syntax (based on BeanUtils) is way too limited
* Totally dependent on Servlet API objects, making (a) unit tests hard,
and (b) implementations on portlet difficult
* Key functional areas (such as Tiles and Validator) can be
pretty obtuse to configure
* No model of user interface components -- just hard coded HTML rendering
None of these things are totally unusable -- but they all need improvement.
Craig
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
