struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From szerintedmi <szerinte...@gmail.com>
Subject Re: PRG pattern question
Date Mon, 31 May 2010 10:34:25 GMT
Thanks all for the help...

The store interceptor definitely is part of the solution.  (If you lost and
nothing else helps read the documentation :) )

I still need  to sort out how to "redirect" the params. I'm thinking about
to make an interceptor in similar way how the store interceptor works:

1. the interceptor stores all params (except files?) in the http session

2. the next request cleans them up from the session and retrieves them if
interceptor in RETRIEVE mode or if in AUTOMATIC mode it retrieves only if
the request is a response to a redirect action.

If there is no next request It would disappear when the http session
timeouts.

It would make sense to add this interceptor in STORE mode to all actions
where we post data. The response in case of a form error would be
redirectAction to the orignal action (which originally populated the form)
where the interceptor could RETRIEVE params.

This new interceptor combined with the store interceptor might solve this
PRG issue and let me make a "perfect" PRG workflow with nicely working
browser back button.

However I agree with Greg that's not such a good idea to store staff in http
session..

Need think over what this causes if the result is success and the next
action is a form too (with this interceptor added). The next action
RETRIEVEs params from the previous post...

What is your opinion? Would this interceptor make sense?

Thanks,

Peter

---------- Forwarded message ----------
From: Alex Rodriguez Lopez <alopez@flordeutopia.pt>
To: user@struts.apache.org
Date: Thu, 27 May 2010 13:15:14 +0100
Subject: Re: PRG pattern question
Em 26-05-2010 16:57, Chris Pratt escreveu:

> If you search the forum, someone posted an Interceptor (quite a while ago)
> that saves the Action/Field Errors/Messages in the Session so that they
> will
> survive a redirect.  It could easily be extended to do what you require.
>   (*Chris*)
>

I think this interceptor is already included in S2.

What I use:

<!-- Action messages and errors auto-stored in session -->
                       <interceptor-ref name="store">
                               <param name="operationMode">
AUTOMATIC</param>
                       </interceptor-ref>

And it does what it says :D


> On Wed, May 26, 2010 at 5:45 AM, szerintedmi<szerintedmi@gmail.com>
>  wrote:
>
>  Hi Everybody,
>>
>> I would like to ask some advice implementing PRG pattern with struts2
>> (using
>> 2.0.14).
>>
>> I can easily handle a normal scenario :
>> 1.GET showItem.action?itemId=1
>>    result: showItem.jsp
>> 2. POST saveItem.action
>>   result: redirect-action: success?itemId=1
>> 3. GET success?itemId =1
>>  result: success.jsp
>>
>> Browser back works perfectly with this workflow.
>>
>> However if there is a form error at step 2.:
>> 1. GET showItem.action?itemId=1
>>  result: showItem.jsp
>> 2.1 POST saveItem.action
>>   result: showItem.jsp (with field/action errors)
>> 2.2 POST saveItem.action (user fixed errors on form)
>>  result: redirect-action: success?itemId=1
>> 3. GET success?itemId=1
>>  result: success.jsp
>>
>> In this scenario if the user press back after the 3rd step he gets a page
>> with saveItem.action url (without params) and with a re-submit browser
>> alert.
>>
>> If a form validation error happens I could use a redirect-action result to
>> showItem.action at step 2.1.
>> But that way I'm loosing all the posted form data and the data
>> field/action
>> errors.
>>
>> Alternativelly I could use the same action to show and save, that way url
>> would be showItem after 2.1 but still without url params. I could hack url
>> query string to the reponse but still have re-submit alerts from browser
>> after user press back button because that was a result of a post.
>>
>> What is the best practice to handle form errors with struts if I want to
>> implement Post-Redirect-Get pattern?
>>
>> Thanks,
>>
>> Peter
>>
>
Em 26-05-2010 16:57, Chris Pratt escreveu:

If you search the forum, someone posted an Interceptor (quite a while ago)
that saves the Action/Field Errors/Messages in the Session so that they will
survive a redirect. It could easily be extended to do what you require.
(*Chris*)

I think this interceptor is already included in S2.

What I use:

<!-- Action messages and errors auto-stored in session --> <interceptor-ref
name="store"> <param name="operationMode">AUTOMATIC</param>
</interceptor-ref>

And it does what it says :D

On Wed, May 26, 2010 at 5:45 AM, szerintedmi<szer...@gmail.com> wrote:

Hi Everybody,

I would like to ask some advice implementing PRG pattern with struts2 (using
2.0.14).

I can easily handle a normal scenario : 1.GET showItem.action?itemId=1
result: showItem.jsp 2. POST saveItem.action result: redirect-action:
success?itemId=1 3. GET success?itemId =1 result: success.jsp

Browser back works perfectly with this workflow.

However if there is a form error at step 2.: 1. GET showItem.action?itemId=1
result: showItem.jsp 2.1 POST saveItem.action result: showItem.jsp (with
field/action errors) 2.2 POST saveItem.action (user fixed errors on form)
result: redirect-action: success?itemId=1 3. GET success?itemId=1 result:
success.jsp

In this scenario if the user press back after the 3rd step he gets a page
with saveItem.action url (without params) and with a re-submit browser
alert.

If a form validation error happens I could use a redirect-action result to
showItem.action at step 2.1. But that way I'm loosing all the posted form
data and the data field/action errors.

Alternativelly I could use the same action to show and save, that way url
would be showItem after 2.1 but still without url params. I could hack url
query string to the reponse but still have re-submit alerts from browser
after user press back button because that was a result of a post.

What is the best practice to handle form errors with struts if I want to
implement Post-Redirect-Get pattern?

Thanks,

Peter

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