struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Roughley <>
Subject Re: [s2] The death of the .action extension
Date Mon, 10 Sep 2007 14:44:17 GMT
The one issue that I haven't found a good solution for (and my apologies 
if it exists in the smartURLs package - it's on my list of things to 
look at) is when an action class needs to be mapped to multiple URL 
actions potentially different packages.  This is one time that I find 
myself falling back to XML configuration, when I would prefer to use 
annotations.  Is anyone working on anything like this?


PS - and thanks Don, now I have to scrub a good part of a chapter on 
ActionMappers ;-)

James Holmes wrote:
> +1
> Ted, I'm with you 100%. James Mitchell and Bill Siggelkow have been preaching to
> me about Rails for 6 months now and I have finally taken the time to dig in
> deeper. And they are right! It has some amazing concepts. I can't wait to see how
> we can evolve Struts towards achieving some of the excellent concepts implemented
> in Rails.
> james
> On Mon Sep 10  9:55 , 'Ted Husted' <> sent:
>> I'm on board with Don's direction, and I'd like to try doing a
>> ReSTful, Zero-Configuration, Code Behind MailReader this week, based
>> on Brian's SmartURLs plugin, which is putting it all together in a
>> single package.
>> I believe the key point is that we have to develop architectures and
>> coding paradigms that let us "say it once". A very good way to say it
>> once is to say it with naming conventions, and to say it the URI. (And
>> when that doesn't work, annotations!)
>> Many of us are already use conventions and packed URIs, we just
>> haven't been telling the *framework* enough about our conventions so
>> that it could follow along on its own.
>> Personally, I don't see this as a move away from the WebWork or Struts
>> coding styles, but a natural progression. (Code-behind is wildcards
>> without the wildcards.) We've been trying to write applications this
>> way all along. We just couldn't see the architectural forest through
>> the  XML-strewn trees. :)
>> -Ted.
>> On 9/8/07, Don Brown> wrote:
>>> Personally, I think we have a lot to learn from rails as they play
>>> very well off the strengths of the action-based Model2 architecture.
>>> Action-based frameworks strengths:
>>>  * Simple workflow as in URL -> Action -> View
>>>  * Intuitive (using conventions) URL -> Action mappings
>>>  * RESTful by being close the the HTTP protocol
>>>  * Scalable by not storing view state on the server
>>>  * Lightweight in terms of code size and concepts needed to master
>>> As our goal is to make developing scalable applications easier and
>>> quicker, I think we have a lot to learn from rails.  I hope to spend
>>> some time beefing up the RESTful aspects of Struts 2 both for web
>>> services and for regular HTML-based applications.  You are right in
>>> that there are a lot of options in Struts 2, and we need to do a
>>> better job of providing a simple front to Struts 2 that doesn't
>>> bombard you with all its options and features.
>>> As the web moves to embrace more and more Ajax and web service
>>> functionality, I think Struts 2 and its action-based architecture will
>>> be well-suited to meet those needs.  If you want to drop components on
>>> a page, obviously Struts 2 isn't for you, but if you want a framework
>>> on which to build a scalable, public-facing web application supporting
>>> mobile, web service, and Ajax clients, I hope Struts 2 will be the
>>> logical choise.
>>> Don
>>> On 9/9/07, Tom Schneider> wrote:
>>>> Don Brown wrote:
>>>>> Right, and that's why I didn't move to kill it off for 2.1.  Give it
>>>>> some time, let the feature get some exercise, then if all agree, we
>>>>> could change the default later.  As with any new feature, I'd put it
>>>>> in a sort of experimental category for at least one major release.
>>>> So, do you have a final goal in mind for this or are you just working to
>>>> open up options?  I'd be very interested in hearing of the any options
>>>> we have.  Are we moving more towards Rails, or are there other better
>>>> alternatives?
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message