You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Erik Hatcher <ja...@ehatchersolutions.com> on 2003/08/14 02:51:30 UTC
Bye struts-dev
Normally I don't make a parting post to an e-mail list when
unsubscribing, I just subtly disappear. But Struts has been a big part
of my past couple of years professionally. I'll be signing off this
e-mail list in a few days (to give time to see any juicy replies this
might generate first :). My day job development team has decided to
use Tapestry for our next project. It's always nice to get less e-mail
than more, and the discussions of Struts2 are so far removed from my
daily coding efforts that its best for me to sign off for now.
The app we just successfully deployed is completely in Struts, and the
tricks we pulled with it have been the subject of my TheServerSide
Symposium and No Fluff, Just Stuff symposium presentations, as well as
the recent articles on Struts-XDoclet integration at the JavaPro
website. Struts gave us enough flexibility to plug in cool things like
resources from a database, a label taglib that leveraged Validator and
ActionErrors information, and more.
So, Struts has served me well. Its far from perfect though, and in the
spirit of *constructive* criticism here are some areas to consider.
Struts does not provide is true UI components that can be reused and
encapsulate JavaScript, images, or other resources (i.e. there is a
whole lot of cut-and-paste and trial and error).
Struts Actions are also hard to test, and things that are hard or no
fun get neglected by developers (i.e. dependence on container API in
Struts Actions is a real drawback for testing). Sure, Cactus or Mock
use of StrutsTestCase are better than nothing, but its tough to mock
business methods in Struts actions such that a database and container
are not needed.
While exploring web frameworks, I spent a bit of time with WebWork2. I
really like what I see going on there. Its lightweight,
straightforward, and powerful. The interceptors add tons of
flexibility. The IoC aspect of it decouples actions from the container
and even concrete business implementations (making testing a WW2 action
a real joy). The command-pattern is clean. The discussions of Struts2
seem to be aiming towards the same thing WebWork2 already is. I'd
highly recommend those that are hard-core Struts developers give
WebWork2 a good look and either jump ship or start seriously
incorporating these ideas into the Struts2 architecture. Using
interfaces is one immediate take-away from WW2 :)
I'm sure that our foray into Tapestry will not be without its share of
hurdles, and probably reinventing some wheels we mastered with Struts,
and judgment is still out on how tough testing will be with Tapestry.
I will continue to be a Struts developer for maintaining and enhancing
the app we just deployed, so I'm not going to totally give it up - I
just want to reduce my e-mail influx. And I will still present my
Advanced Struts presentation several more times this year at No Fluff,
Just Stuff symposiums.
I look forward to checking out the Struts2 architecture and code as it
evolves.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Bye struts-dev
Posted by Ted Husted <hu...@apache.org>.
Of course, there's no debating Erik's points. =:)
Though, AFAIK, we haven't been discussing Struts 2 at all. A while back,
we came to a consensus that the Struts 2.x series would be based on
Servlet 2.4 / JSP 2.0, but that's it.
The recent discussions are all things that we can do with the 1.x
series. Craig thinks his new request processor will be able to snap in
over the the 1.1 version, and I agree. The ActionContext signature could
be brought in the same way we brought in the execute signature. The
ActionForward page controller could also be an extension of what we
have. If the ActionForward type property isn't used, the current
behavior prevails.
Meanwhile, something I'd like to see would be a Struts extension that
would allow us to use Tapestry UI components for view. We already have
such for JSPs, JSTL, JSF, Velocity, XLST, and Coccoon, why not Tapestry
as well? [Just putting a bug in your ear =:)]
-Ted.
Erik Hatcher wrote:
> Normally I don't make a parting post to an e-mail list when
> unsubscribing, I just subtly disappear. But Struts has been a big part
> of my past couple of years professionally. I'll be signing off this
> e-mail list in a few days (to give time to see any juicy replies this
> might generate first :). My day job development team has decided to use
> Tapestry for our next project. It's always nice to get less e-mail than
> more, and the discussions of Struts2 are so far removed from my daily
> coding efforts that its best for me to sign off for now.
>
> The app we just successfully deployed is completely in Struts, and the
> tricks we pulled with it have been the subject of my TheServerSide
> Symposium and No Fluff, Just Stuff symposium presentations, as well as
> the recent articles on Struts-XDoclet integration at the JavaPro
> website. Struts gave us enough flexibility to plug in cool things like
> resources from a database, a label taglib that leveraged Validator and
> ActionErrors information, and more.
>
> So, Struts has served me well. Its far from perfect though, and in the
> spirit of *constructive* criticism here are some areas to consider.
>
> Struts does not provide is true UI components that can be reused and
> encapsulate JavaScript, images, or other resources (i.e. there is a
> whole lot of cut-and-paste and trial and error).
>
> Struts Actions are also hard to test, and things that are hard or no fun
> get neglected by developers (i.e. dependence on container API in Struts
> Actions is a real drawback for testing). Sure, Cactus or Mock use of
> StrutsTestCase are better than nothing, but its tough to mock business
> methods in Struts actions such that a database and container are not
> needed.
>
> While exploring web frameworks, I spent a bit of time with WebWork2. I
> really like what I see going on there. Its lightweight,
> straightforward, and powerful. The interceptors add tons of
> flexibility. The IoC aspect of it decouples actions from the container
> and even concrete business implementations (making testing a WW2 action
> a real joy). The command-pattern is clean. The discussions of Struts2
> seem to be aiming towards the same thing WebWork2 already is. I'd
> highly recommend those that are hard-core Struts developers give
> WebWork2 a good look and either jump ship or start seriously
> incorporating these ideas into the Struts2 architecture. Using
> interfaces is one immediate take-away from WW2 :)
>
> I'm sure that our foray into Tapestry will not be without its share of
> hurdles, and probably reinventing some wheels we mastered with Struts,
> and judgment is still out on how tough testing will be with Tapestry.
>
> I will continue to be a Struts developer for maintaining and enhancing
> the app we just deployed, so I'm not going to totally give it up - I
> just want to reduce my e-mail influx. And I will still present my
> Advanced Struts presentation several more times this year at No Fluff,
> Just Stuff symposiums.
>
> I look forward to checking out the Struts2 architecture and code as it
> evolves.
>
> Erik
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
--
Ted Husted,
Junit in Action - <http://www.manning.com/massol/>,
Struts in Action - <http://husted.com/struts/book.html>,
JSP Site Design - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Bye struts-dev
Posted by Don Brown <mr...@twdata.org>.
On Wed, 13 Aug 2003, Erik Hatcher wrote:
<snip />
> While exploring web frameworks, I spent a bit of time with WebWork2. I
> really like what I see going on there. Its lightweight,
> straightforward, and powerful. The interceptors add tons of
> flexibility. The IoC aspect of it decouples actions from the container
> and even concrete business implementations (making testing a WW2 action
> a real joy). The command-pattern is clean. The discussions of Struts2
> seem to be aiming towards the same thing WebWork2 already is. I'd
> highly recommend those that are hard-core Struts developers give
> WebWork2 a good look and either jump ship or start seriously
> incorporating these ideas into the Struts2 architecture. Using
> interfaces is one immediate take-away from WW2 :)
I totally agree. Lars Hoss has donated code to Struts Applications
(http://struts.sf.net) which implements Action interceptors and WW2-style
IoC. We are currently in the process of cleaning the code up for a
release. We are also looking at extracting the Action invoking
code to support arbitrary actions as well as Struts Action-derived classes
as XWork does. We hope the project will be a furtile testbed for future
Struts architecture features, as well as support existing Struts
applications (Struts 1.1+).
Good luck on your next project, Erik, and thanks for the suggestions.
Don
> I'm sure that our foray into Tapestry will not be without its share of
> hurdles, and probably reinventing some wheels we mastered with Struts,
> and judgment is still out on how tough testing will be with Tapestry.
>
> I will continue to be a Struts developer for maintaining and enhancing
> the app we just deployed, so I'm not going to totally give it up - I
> just want to reduce my e-mail influx. And I will still present my
> Advanced Struts presentation several more times this year at No Fluff,
> Just Stuff symposiums.
>
> I look forward to checking out the Struts2 architecture and code as it
> evolves.
>
> Erik
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org