struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 866] - Clean Way to Add Parameters to Redirecting Forward
Date Sat, 31 Jan 2004 00:19:02 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=866>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=866

Clean Way to Add Parameters to Redirecting Forward





------- Additional Comments From jakartauser@yahoo.com  2004-01-31 00:19 -------

My patch will do the following:

1. Add ActionRedirect methods
   - new constructors which accept a ServletContext (needed to evaluate 
messages).
   - new methods:
     addMessage(HttpServletRequest request, ActionMessage message)
     addMessage(HttpServletRequest request, String key, ActionMessage message)
     addErrorMessage(HttpServletRequest request, ActionMessage message)
     addErrorMessage(HttpServletRequest request, String key, ActionMessage 
message)
      The "key" is for specifying the resource bundle to use.

2. In the ActionRedirect class, the message is evaluated using 
MessageResources. This is done here because the actual message may need 
additional parameters ("new ActionMessage(key, arg0, arg1)") that should not 
(and cannot) be passed as redirect params.

3. The resulting message is added to the redirect params using a unique param 
name. A "unique param name" is easy to set up when you're working on a 
particular application, but for a framework, the user should be able to specify 
this. I've added "msgParamName" and "errorParamName" to ControllerConfig to 
allow the user to specify the request parameter to use for normal msgs and 
error msgs. (I was thinking "redirectMessageParamName" 
and "redirectErrorMessageParamName" were too long.)  

4. In RequestProcessor.process(request,response), after processActionPerform() 
and before processForwardConfig() is called, I inserted a 
processRedirectMessages() call.  In that method, the request is checked for 
params with names specified by "msgParamName" and "errorParamName".  If 
messages are present, ActionMessage objects are created to hold them and they 
are added to the existing ActionMessages that is referred to by 
Globals.MESSAGE_KEY or Globals.ERROR_KEY, depending on whether the message is 
for an error or not.  (If the needed ActionMessages object doesn't exist, it is 
created).

5. For the redirected ActionMessage to work, the user must include an entry in 
the app's message resources:

org.apache.struts.action.redirect.message={0}


The use of ActionRedirect changes slightly:

ActionRedirect redirect = getActionRedirect(mapping.findForward("target"));
redirect.addParameter("param1","value1");
redirect.addParameter("param2","value2");
redirect.addMessage(request, new ActionMessage("msg.key",obj1,obj2));
redirect.addErrorMessage(request, new ActionMessage("error.key",errorParams));
return redirect;

getActionRedirect() is a convenience method in the Action class which creates 
an ActionRedirect instance with the servlet context already provided.

If the user creates an ActionRedirect without a servlet context, then attempts 
to add an ActionMessage, an IllegalStateException is thrown.  (If the user even 
tests the redirect-with-a-msg even once, this would be caught while in dev).

I've updated my struts source base with the latest CVS changes, and used that 
to enter my changes.  I've tested it with a test app, and I'm now preparing 
unit tests that I can submit with the patch.

There are several areas here where people might want to chime in, and so I'm 
posting these details here before I submit anything.

---------------------------------------------------------------------
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