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?

/Ian

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' <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]> 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 [EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to