Hi! This is a valid point. The URL becomes incorrect and a reload can lead to a different outcome than expected. If the action being performed is e.g. some kind of next page action it might lead to a second page flip. One way to get around this would be passing along a variable to indicate from where the action is being performed, i.e. which page you are on.
I note several people are saying that it might be a design issue in what I am trying to do, but let's approach this from a different angle: Does anyone think that the redirect-action result type should not be used? that there are not cases where you have to use it because the JSPs have dependencies to the properties of the actions. In this case why can't Struts2 just drop the redirect and create an instance of the next action and execute it with the properties provided via the action-mappings.xml? Sure, it might mess up the URL and there might be issues if the action is ServletRequestAware, but is that all? As I was trying to say before chain is not the answer for this. It will e.g. not work if the actions have different property names. / Fredrik Lindberg (2012-09-27). On Thu, Sep 27, 2012 at 5:19 AM, Dale Newfield <[email protected]> wrote: > Nobody on this thread pointed out the point of the POST-redirect-GET pattern: > to make sure the content displayed in the browser matches the URL in the > address bar. When it doesn't, the user hitting reload or forward/back (on > what appears to be a page displaying state, not the explanation of the result > of a state change operation) might cause the POST action to happen again > instead of just reloading the data you display when the POST is complete. If > you value server CPU over site usability, by all means use any of the > suggestions previously offered. > > -Dale > --------------------------------------------------------------------- > 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]
