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:[EMAIL PROTECTED] Behalf Of Martin Cooper > Sent: August 1, 2003 8:32 AM > To: [EMAIL PROTECTED] > Subject: Re: Addition of two new actions > > > > "Steve Raeburn" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
