struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From joey <realghost...@gmail.com>
Subject Re: [S2] action mapping best practice
Date Tue, 03 Apr 2007 09:08:23 GMT
In the latest struts2 version 2.0.6,I only found <action name="*Login_**"method
="*{1}*" class ="*mailreader2.Login*">.There was no <action name="*Login*"**
class="mailreader2.Login">...
So you confused me.
Regards
joey

On 4/3/07, Jae K <invrnrv@gmail.com> wrote:
>
> I'm talking about struts2. My post was a reaction to that config file. I
> was
> just pointing out what my thoughts were on the best practices. I'm not a
> developer on the struts team :)
>
> - Jae
>
> On 4/2/07, joey <realghost819@gmail.com> wrote:
> >
> > Which version of struts2 are you talking about?
> > I just found <action name="*Login_**" method="*{1}*" class="*
> > mailreader2.Login*"> in configuration files.
> > You just confused me.
> > On 4/3/07, Jae K <invrnrv@gmail.com> wrote:
> > >
> > > I have a comment about the MailReader tutorial.
> > >
> > > This is the action declaration for the Login action:
> > >
> > > <action name="*Login_**" method="{1}" class="mailreader2.Login">...
> > > <action name="*Login*"** class="mailreader2.Login">...
> > >
> > > To invoke this action, the user agent would first GET request
> > Login_input,
> > > and then POST to Login to submit the form or Login_cancel to cancel,
> > etc.
> > >
> > > IMHO this is a *bad* way to declare your actions. Here are the
> reasons:
> > > 1. There is a duplication of URLs. There are at least two URL
> resources
> > > with
> > > the login form: /Login_input and /Login (/Login will display the form
> if
> > > there was a field error)
> > > 2. There is a duplication of action declarations. In this example
> there
> > > are
> > > two declarations, one for Login_* and Login.
> > > 3. There are needlessly many methods in the action class.
> > > 4. It's not a restful interface
> > >
> > > The source of the problem is with the ValidationInterceptor class (and
> > its
> > > subclasses). Whether or not validation occurs should not depend solely
> > on
> > > the method name (input, submit, etc), but also the HTTP verb
> (GET/POST).
> > A
> > > more intelligent ValidationInterceptor subclass would solve all of
> these
> > > problems.
> > >
> > > Solution:
> > > 1. I created a PostMethodValidationInterceptor that extends
> > > ValidationInterceptor to validate only on POST requests.
> > > 2. My action support superclass has two methods: isInvalid() and
> > > isFormPosted().
> > >
> > > Now I only need one action mapping, and only one method in my action
> > class
> > > as follows:
> > >
> > > public class Input extends MySupport {
> > > ...
> > >    public String execute() throws Exception{
> > >      if(!isValid() || !isFormPosted)
> > >        return "input";
> > >      //continue with input logic
> > > ...
> > > }
> > >
> > > The isValid and isFormPosted methods are very easy to implement. Let
> me
> > > know
> > > if anybody wants any of my source files.
> > >
> > > - Jae
> > >
> >
>

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