struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Raeburn" <sraeb...@apache.org>
Subject RE: Addition of two new actions
Date Fri, 01 Aug 2003 16:52:38 GMT
SuccessAction does already exist in Scaffold. That version is slightly
different as it uses the Tokens constants class. I don't really see what
that would buy us, as the user would still need to know what name to enter
for the ActionForward. I wouldn't want to tie a core Action to the scaffold
package and if we added the constant to Globals it just makes it harder for
the user to figure out what to name his ActionForward. (Imagine the
Javadoc - "This action forwards to an ActionForward specified by the value
of the org.apache.struts.Globals.SUCCESS constant" vs. "This action forwards
to an ActionForward named "success".)

I'm also throwing an exception if the "success" ActionForward is not found
to make the configuration problem very clear.

ForwardAction and using 'forward= ' on the ActionMapping both require a
context relative path. SuccessAction adds flexibility by allowing you to
specify the ActionForward in the normal way, including using module or
context relative paths.

In addition, tools vendors may be better able to validate a regular
ActionFoward configuration than the ForwardAction where the path is
specified via the all-purpose 'parameter'. In order to validate the path as
a parameter, you require knowledge of the Action class whereas the path of
an ActionForward definition can be more easily validated. (I'm basing this
on my experience with WebSphere Studio).

I did consider suggesting that FowardAction be deprecated in favour of
SuccessAction, because its function would be encompassed by the new action.
I held off because I thought that might be controversial :-)

I hope this better explains some of the reasons why I prefer SuccessAction
to the alternatives. I apologize for not explaining myself more fully in the
first place.

Steve

> -----Original Message-----
> From: news [mailto:news@main.gmane.org]On Behalf Of Martin Cooper
> Sent: August 1, 2003 8:32 AM
> To: struts-dev@jakarta.apache.org
> Subject: Re: Addition of two new actions
>
>
>
> "Steve Raeburn" <sraeburn@apache.org> wrote in message
> news:JBEMLPKGGEDFEFLNNCFFKEJLDCAA.sraeburn@apache.org...
> > I'd like to add two new actions to org.apache.struts.actions that I find
> > particularly useful.
> >
> > 1. SuccessAction - A simple action that forwards control to an
> ActionFoward
> > named "success".
>
> This already exists, in contrib:
>
>     org.apache.struts.scaffold.SuccessAction
>
> or, as David pointed out, you could use ForwardAction instead.
>
> --
> Martin Cooper
>
>
> >
> > This is a very simple action, but I find it exceptionally useful,
> > particularly in the early stages of development when it can act as a
> > placeholder for as-yet undeveloped actions.
> >
> >   public ActionForward execute(
> >     ActionMapping mapping,
> >     ActionForm form,
> >     HttpServletRequest request,
> >     HttpServletResponse response)
> >     throws Exception {
> >
> >     ActionForward forward = mapping.findForward("success");
> >       if (forward == null) {
> >         String message =
> >           messages.getMessage("success.required", mapping.getPath());
> >         log.error(message);
> >         throw new ServletException(message);
> >       }
> >       return forward;
> >     }
> >
> > 2. ParameterDispatchAction - A DispatchAction that selects a handler
> method
> > using the value of the ActionMapping parameter.
> >
> > This is as per the suggestion by Anthony Kay via Bugzilla
> > <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17117>,
> except I prefer
> > the name ParameterDispatchAction to his suggestion of
> ConfigDispatchAction
> > as I think it's more descriptive of what the class actually does. Other
> than
> > the name change, I've just tidied up the Javadoc and changed the
> > 'unspecified' method to throw an Exception (as in DispatchAction) rather
> > than return an Http error code.
> >
> > If no one has any problems with adding these two, I'll put them in
> tomorrow.
> >
> >
> > Steve
>
>
>
>
> ---------------------------------------------------------------------
> 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


Mime
View raw message