Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: pass (athena.apache.org: domain of ted.husted@gmail.com
 designates 209.85.198.189 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=rdB9e/TywqKpDPDTWeIoAc5UErIz/IUEF+/JxdsS6EZCbkKPFMQ+4jiMQkQXFPu9KgYvBIsgo/WB2oYS7ketS9WOBIFEQiLQ/neBRLds1u2SJpJYmrOnRX5S1FukguX/WvO/V6lx++YlKXSaTCENiiFLhMNvZk4xWEHQiganK5o=
Message-ID: <8b3ce3790709100655w58138977v33a5a6ab3b97b53@mail.gmail.com>
Date: Mon, 10 Sep 2007 09:55:34 -0400
From: "Ted Husted" <husted@apache.org>
Sender: ted.husted@gmail.com
To: "Struts Developers List" <dev@struts.apache.org>
Subject: Re: [s2] The death of the .action extension
In-Reply-To: <436d9a250709081858i6d4b56b1heb7e55030890b2a@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <436d9a250709080032v4bd74f61vb4eb18c9b0231530@mail.gmail.com>
	 <46E2A7C2.90703@gmail.com>
	 <436d9a250709080737n278923d3u43c73e2071d6f591@mail.gmail.com>
	 <46E2C592.1090107@gmail.com>
	 <436d9a250709081858i6d4b56b1heb7e55030890b2a@mail.gmail.com>

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 <mrdon@twdata.org> 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 <schneidh@gmail.com> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org