RE: [S2] ActionMessages and redirects
Hi,
Thanks for your response. Yes, I think the interceptor will do. However, it
just feels a bit clumsy to write 6 lines of XML in order to get
functionality that Struts 1 provided in one. It may be a great solution for
cases where your action messages have to survive multiple redirects but in
99.99% of my cases it is just one...and I am using quite a few of those in
my apps. Thus, I miss the Struts 1 solution :-)
Regards,
Gunnar
Al Sutton-3 wrote:
>
> Hi Gunnar,
>
> I've been through the same thing, so I can help you out :).
>
> If your actions extend com.opensymphony.xwork2.ActionSupport you can then
> call the method;
>
> addActionMessage("string")
>
> Or
>
> addActionError("string");
>
> Please note, "string" is the literal message, not a key into a properties
> file.
>
> If you want to use a properties file for multi-language systems you need
> to
> do the following;
>
> addActionMessage(getText("key"))
>
> Or
>
> addActionError(getText("key"))
>
> And create a file called package.properties in your action package (or at
> some point above in the package hierarchy) which has the translations.
>
> You will need to use the message store interceptor where you are using a
> redirect (i.e. you will need it in the redirect to the get), you should
> note
> though, at the moment there appears to be a bug in that if you use
> addActionError, the message store interceptor, and you have the validation
> interceptor enabled you will get redirected to the input result of the
> action after the redirect :(.
>
> Hope this helps,
>
> Al.
>
> -Original Message-
> From: Gunnar Hillert [mailto:[EMAIL PROTECTED]
> Sent: 04 June 2007 05:52
> To: user@struts.apache.org
> Subject: [S2] ActionMessages and redirects
>
>
> Hi,
>
> Still learning but I am really going to like Struts 2. An area where I
> find
> it a bit lacking though (Compared to Struts 1) is the support for action
> messages to survive redirects.
>
> I really like to follow the 'Post/Redirect/Get pattern' for most of my
> actions.
> (See also
> http://www.theserverside.com/patterns/thread.tss?thread_id=20936)
>
> Therefore in most of my actions I have the requirement that my success
> messages survive the next redirect.
>
> In Struts 1 I can do:
>
> messages.add(ActionMessages.GLOBAL_MESSAGE,
>new ActionMessage("user.added"));
> saveMessages(request.getSession(), messages);
>
> But there is nothing like this in Struts 2.
>
> I did not find too much information about this requirement in Struts 2.
> There are 2 open issues in Jira that touch the issue:
>
> https://issues.apache.org/struts/browse/WW-1623
> https://issues.apache.org/struts/browse/WW-1572
>
> On of the issues mentions the MessageStore interceptor but that looks a
> bit
> like overkill to me. (See also
> http://cwiki.apache.org/WW/message-store-interceptor.html)
>
> Thus, for right now I am using Appfuse's solution of using a custom
> filter.
> (See
> https://appfuse-light.dev.java.net/source/browse/appfuse-light/trunk/src/mai
> n/java/org/appfuse/web/MessageFilter.java)
>
> This works great but somehow feels like a 'hack' (Had to do the same for
> my
> Spring MVC projects.)
>
> * * *
>
> In a perfect world I would like to see a feature similar to Ruby on Rails'
> Flash which allows you to not only store messages but any object in a
> Flash,
> and hence those objects survive the next redirect.
>
> See also http://api.rubyonrails.com/classes/ActionController/Flash.html
>
> But for the time being I would be already quite happy if there was a
> simple
> and standardized way to have my actionMessages survive redirects.
>
> What is the status on that? Is this something that will be added to one of
> the next Struts 2 releases?
>
> Thanks a lot!
>
> Regards,
>
> Gunnar Hillert
>
> --
> View this message in context:
> http://www.nabble.com/-S2--ActionMessages-and-redirects-tf3863054.html#a1094
> 3759
> Sent from the Struts - User mailing list archive at Nabble.com.
>
>
> -
> 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]
>
>
>
--
View this message in context:
http://www.nabble.com/-S2--ActionMessages-and-redirects-tf3863054.html#a10967300
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: [S2] ActionMessages and redirects
Dave, The problem is that if your action uses addActionError and returns INPUT to get a redirect to another action the validation also uses teh input result of the action you've been redirected to. I agree that upon an error you want to go back to the input page, but if your error is added in ActionB, and you're using an action as the input page (ActionA), and you have the relevant interceptors enabled, the current behaviour sends you to the input page of the input Action of the action where the error was added (i.e. the input result of ActionA) instead of just the input action of where the error occurred (i.e. the input result of ActionB). Al. Dave Newton wrote: --- Al Sutton <[EMAIL PROTECTED]> wrote: at the moment there appears to be a bug in that if you use addActionError, the message store Interceptor, and you have the validation interceptor enabled you will get redirected to the input result of the action after the redirect :( I'm not sure I'd classify that as a bug. The default use case (IMO) is that if you have errors you want to go back to the input page. If you want to work around the default behavior then take a look at the DefaultWorkflowInterceptor source and create your own that does something different, or use messages, which are not handled as errors are. d. Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/ - 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]
RE: [S2] ActionMessages and redirects
--- Al Sutton <[EMAIL PROTECTED]> wrote: > at the moment there appears to be a bug in that if > you use addActionError, the message store > Interceptor, and you have the validation interceptor > enabled you will get redirected to the input result > of the action after the redirect :( I'm not sure I'd classify that as a bug. The default use case (IMO) is that if you have errors you want to go back to the input page. If you want to work around the default behavior then take a look at the DefaultWorkflowInterceptor source and create your own that does something different, or use messages, which are not handled as errors are. d. Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [S2] ActionMessages and redirects
Hi Gunnar,
I've been through the same thing, so I can help you out :).
If your actions extend com.opensymphony.xwork2.ActionSupport you can then
call the method;
addActionMessage("string")
Or
addActionError("string");
Please note, "string" is the literal message, not a key into a properties
file.
If you want to use a properties file for multi-language systems you need to
do the following;
addActionMessage(getText("key"))
Or
addActionError(getText("key"))
And create a file called package.properties in your action package (or at
some point above in the package hierarchy) which has the translations.
You will need to use the message store interceptor where you are using a
redirect (i.e. you will need it in the redirect to the get), you should note
though, at the moment there appears to be a bug in that if you use
addActionError, the message store interceptor, and you have the validation
interceptor enabled you will get redirected to the input result of the
action after the redirect :(.
Hope this helps,
Al.
-Original Message-
From: Gunnar Hillert [mailto:[EMAIL PROTECTED]
Sent: 04 June 2007 05:52
To: user@struts.apache.org
Subject: [S2] ActionMessages and redirects
Hi,
Still learning but I am really going to like Struts 2. An area where I find
it a bit lacking though (Compared to Struts 1) is the support for action
messages to survive redirects.
I really like to follow the 'Post/Redirect/Get pattern' for most of my
actions.
(See also http://www.theserverside.com/patterns/thread.tss?thread_id=20936)
Therefore in most of my actions I have the requirement that my success
messages survive the next redirect.
In Struts 1 I can do:
messages.add(ActionMessages.GLOBAL_MESSAGE,
new ActionMessage("user.added"));
saveMessages(request.getSession(), messages);
But there is nothing like this in Struts 2.
I did not find too much information about this requirement in Struts 2.
There are 2 open issues in Jira that touch the issue:
https://issues.apache.org/struts/browse/WW-1623
https://issues.apache.org/struts/browse/WW-1572
On of the issues mentions the MessageStore interceptor but that looks a bit
like overkill to me. (See also
http://cwiki.apache.org/WW/message-store-interceptor.html)
Thus, for right now I am using Appfuse's solution of using a custom filter.
(See
https://appfuse-light.dev.java.net/source/browse/appfuse-light/trunk/src/mai
n/java/org/appfuse/web/MessageFilter.java)
This works great but somehow feels like a 'hack' (Had to do the same for my
Spring MVC projects.)
* * *
In a perfect world I would like to see a feature similar to Ruby on Rails'
Flash which allows you to not only store messages but any object in a Flash,
and hence those objects survive the next redirect.
See also http://api.rubyonrails.com/classes/ActionController/Flash.html
But for the time being I would be already quite happy if there was a simple
and standardized way to have my actionMessages survive redirects.
What is the status on that? Is this something that will be added to one of
the next Struts 2 releases?
Thanks a lot!
Regards,
Gunnar Hillert
--
View this message in context:
http://www.nabble.com/-S2--ActionMessages-and-redirects-tf3863054.html#a1094
3759
Sent from the Struts - User mailing list archive at Nabble.com.
-
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]
