Re: Manually obtain previous action parameters after action "chaining"?
There was a good suggestion about using the MessageStoreInterceptor, but I am
really trying to avoid using Session-based storage for my application,
having been indoctrinated into the RESTful camp at the 2007 Colorado
Software Summit :)
I just discovered that both actions (the one that gets the validation errors
and the target of the chain result) are on the OGNL stack. So, here is what
I did:
> @Override
> public String execute()
> throws Exception
> {
> ValueStack stack = ActionContext.getContext().getValueStack();
> Object penultimate = stack.findValue( "[1].top" );
> if( penultimate instanceof ValidationAware )
> {
> ValidationAware previousAction = (ValidationAware)
> penultimate;
> this.setActionErrors( previousAction.getActionErrors() );
> this.setActionMessages( previousAction.getActionMessages() );
> this.setFieldErrors( previousAction.getFieldErrors() );
> }
> return SUCCESS;
> }
>
I like this approach because it seems clean. But, I am wondering, given the
fact that bean properties are set in the second action, why aren't
"actionErrors", "actionMessages", and "fieldErrors" seen as bean properties
that get automatically set by the ChainingInterceptor?
Anyway, this solution is working for me, and I think I should abstract this
out into an interceptor so that I don't have to pollute my action methods
with this logic. Does anyone have any feedback about this approach? Am I
abusing the OGNL stack? Am I breaking semantics of validation handling? Is
it possible that the first action will not be located on the stack as
"[1].top"?
Thanks for your help!
jjgould wrote:
>
> Ted, et. al.,
>
> I am also interested in accessing the previous action from the target
> action of a "chain" result. But, the reason I want to get to that action
> is not because of any bean properties, but because I need the action
> errors, action messages, and field errors that may have been placed there
> by my validation.
>
>
--
View this message in context:
http://www.nabble.com/-S2--Manually-obtain-previous-action-parameters-after-action-%22chaining%22--tf4601173.html#a13647964
Sent from the Struts - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Manually obtain previous action parameters after action "chaining"?
Ted, et. al.,
I am also interested in accessing the previous action from the target action
of a "chain" result. But, the reason I want to get to that action is not
because of any bean properties, but because I need the action errors, action
messages, and field errors that may have been placed there by my validation.
In my case, action "one" is used to view an object that is an aggregate of a
lot of smaller objects. Action "two" is used to add a new component object
to the collection. However, when there is a validation error on the new
object, the application needs to forward back to action "one" to redisplay
the object and it needs to have the field error messages. The struts.xml
looks like this:
{1}
/WEB-INF/jsp/case/viewCase.jsp
{1}
{1}/view
{1}/view
Any tips you can offer are greatly appreciated.
- Jack Gould
Sherwin-Williams
Cleveland, Ohio, USA
Ted Husted wrote:
>
> Binding two Action classes together that way sounds like a "slippery
> slope" to me. It seems like a better practice to rely on standard
> JavaBean semantics, and access the values that need to be brought
> forward through the usual get and set methods.
>
> One other thing to try, which you may have started to do, would be to
> save the object as a request attribute, as an alternative to the chain
> result. In this case, both Actions would have setRequest and
> getRequest methods.
>
> ActionOne
> getRequest().put("searchParameter",getSearchParameter());
>
> ActionTwo
> setSearchParameter( (SearchParameter) getRequest().get("searchParameter")
> );
>
> The JVM is optimized for property methods, and overall it's a better
> practice to go through the getters and setters than access fields
> directly.
>
> -- HTH, Ted
>
