RE: [s2.0.9] Is there a better way to do this...

[Ezra Jennings <ez...@yahoo.com>]

Hi Al,

I was having what I think was the same problem and have come up with a way
to deal with it (which you may have already figured out by now).

I have my actions set up using Post-Redirect-Get, so that the processing of
a view (form) is its own action and the preparation of the subsequent view
its own action and the processing action gets to the preparation action
using a redirect-action result.  For a concrete example:

PrepareAAction --success--> A.jsp --submits--> ProcessAAction --success
(redirect-action) --> PrepareBAction --success--> B.jsp

also:

ProcessAAction --input (redirect-action) --> PrepareAAction --success-->
A.jsp


I only use the validate() method in the ProcessAAction, not in the
PrepareBAction.

If action errors are added in the ProcessAAction.validate() after A.jsp is
submitted, then the input result is returned which results in a redirect to
the PrepareAAction which will show the A.jsp page again.
To get the action errors transferred from ProcessAAction to PrepareAAction,
I am using the MessageStoreInterceptor, but I found for it to work properly
with validation that the MessageStoreInterceptor has to be at the bottom of
the interceptor stack in RETRIEVE mode for my ProcessXXXActions, but it has
to be at the top of the interceptor stack in STORE mode for my
PrepareXXXActions  (These top and bottom of the interceptor stack references
are probably just its position with respect to the workflow interceptor.)  

What I think happens when the MessageStoreInterceptor is not in the right
order in the interceptor stack:

If the MessageStoreInterceptor is in RETRIEVE mode and it is on top of the
interceptor stack, then yes, PrepareAAction will retrieve the actionErrors
before it runs the workflow interceptor (which calls the validate method).  
The workflow interceptor will then see the action errors and return the
'input' result.  

On the other hand if the MessageStoreInterceptor is in STORE mode and it is
on the bottom of the stack, then the workflow interceptor will run before
the MessageStoreInterceptor and when it hits the workflow interceptor is
will stop going down the interceptor stack and start coming back up the
stack.  Since the MessageStoreInterceptor in STORE mode fires after the
action invocation, it can only do the storing of the actionerrors if it is
on top of the interceptor stack (and fires on the way up the stack).

Hope this helps...
Ezra



Al Sutton-4 wrote:
> 
>> On 9/6/07, Al Sutton <al...@alsutton.com> wrote:
>>> Here's a problem I've come across a couple of times and the solution
>>> I
>>> have feels clunky so I thought I'd throw it out to see if anyone has 
>>> any better ideas;
>>>
>>> I have a form which has a s:select populated from a Map of objects 
>>> which come from a database, at the moment I'm doing the following;
>>>
>>> 1) Action A gets the list from the database
>>> 2) A .JSP displays the form with the s:select and submits to Action B
>>> 3) Action B processes the form.
>>>
>>> This is looks neat until you look at the situation when an error 
>>> occurs.
>>>
>>> In order to ensure that the s:select is correctly filled the error 
>>> result has to send the browser back to Action A, which is being done 
>>> as a redirect. The problem with this is that all actionMessages and 
>>> actionErrors get lost during the redirect, and thus the user can't
> see 
>>> what was wrong. To get around this I use the store interceptor, but
>>> this causes problems if validation is turned on (it will bounce the 
>>> user to the error result of Action A if an errorMessage is present - 
>>> see https://issues.apache.org/struts/browse/WW-1963 for the bug 
>>> report).
>>>
>>> So I end up with the validation interceptor turned off and having to 
>>> hand code some validation, and the store interceptor turned on for 
>>> several actions.
>>>
>>> So has anyone found a better way of handling the "populate list -> 
>>> show list
>>> -> handle errors" situation?
>>>
> 
> 

-- 
View this message in context: http://www.nabble.com/-s2.0.9--Is-there-a-better-way-to-do-this...-tf4391572.html#a13844587
Sent from the Struts - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org