Re: [DEV-IMPLICATIONS] Re: Actionerrors & the Store Interceptor
The action messages and errors are stored in a request attribute which is why the don't survive a redirect. I played around with some ideas and found that Freemarker (the template language used for the tags), is just too dumb to clear session scoped variables (which would survive a redirect and are used by the MessageStoreInterceptor), so I guess we're kind of stuffed until someone works on the core code and comes up with a method that works. Al. P.S. The errors are delt with inside Xwork and not S2.1, so it's not a simple job :(. - Original Message - From: "Chris Pratt" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" Sent: Thursday, April 03, 2008 4:42 PM Subject: Re: [DEV-IMPLICATIONS] Re: Actionerrors & the Store Interceptor On Thu, Apr 3, 2008 at 1:03 AM, Al Sutton <[EMAIL PROTECTED]> wrote: Chris, I'm familiar with the code, but the main problem is that there is a "paper wall" between the StoreInterceptor and the jsp tags, so that one does not know or rely on how the other works. As far as I'm aware this is only a philosophical decision, and there is no technical reason why the tags can't removed information stored in the StoreInterceptor, but I'm pretty sure it would need the nod of those on the dev list to get into the final build. Actually it wouldn't be removing information stored in the StoreInterceptor as much as removing the already shown messages from the lists stored in the Action. So, by the time he StoreInterceptor got control, there would be nothing to store. (*Chris*) - 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: [DEV-IMPLICATIONS] Re: Actionerrors & the Store Interceptor
On Thu, Apr 3, 2008 at 1:03 AM, Al Sutton <[EMAIL PROTECTED]> wrote: > Chris, > > I'm familiar with the code, but the main problem is that there is a "paper > wall" between the StoreInterceptor and the jsp tags, so that one does not > know or rely on how the other works. > > As far as I'm aware this is only a philosophical decision, and there is no > technical reason why the tags can't removed information stored in the > StoreInterceptor, but I'm pretty sure it would need the nod of those on the > dev list to get into the final build. > Actually it wouldn't be removing information stored in the StoreInterceptor as much as removing the already shown messages from the lists stored in the Action. So, by the time he StoreInterceptor got control, there would be nothing to store. (*Chris*) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DEV-IMPLICATIONS] Re: Actionerrors & the Store Interceptor
Chris, I'm familiar with the code, but the main problem is that there is a "paper wall" between the StoreInterceptor and the jsp tags, so that one does not know or rely on how the other works. As far as I'm aware this is only a philosophical decision, and there is no technical reason why the tags can't removed information stored in the StoreInterceptor, but I'm pretty sure it would need the nod of those on the dev list to get into the final build. Al. - Original Message - From: "Chris Pratt" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" Sent: Thursday, April 03, 2008 7:31 AM Subject: Re: Actionerrors & the Store Interceptor On Wed, Apr 2, 2008 at 11:17 PM, Al Sutton <[EMAIL PROTECTED]> wrote: Chris, I've used the StoreInterceptor and my opinion is that it just isn't flexible enough to use. To illustrate the point, consider try following; 1) You have a View Action which displays all of the data of a specific type, which uses the StoreInterceptor in retrieve in order to show confirmation messages from an Update action. 2) You have an Edit Action which sends the user to edit.jsp via the dispatcher result type. edit.jsp has a menu taking the user to other places in the app. 3) You have an Update Action which is called by submitting a form on edit.jsp, this can return the user to edit.jsp using the dispatcher if there is a problem with the form data, or it can take the user to the View Action via a redirect if everything is OK. The Update Action uses the StoreInterceptor in STORE mode in order to send a confirmation back to the View Action. Now, if the user gets to the edit stage submits the form, but has made a mistake which sends them back to edit.jsp, clicks on the menu to go to another action they end up seeing the error message twice, once when the get redirected back to edit.jsp from the UpdateAction, and a second time when they click on any of the links from the menu on edit.jsp. If you want to track the resolution of this, you may want to look at the JIRA issue I raised about 10 months ago... https://issues.apache.org/struts/browse/WW-1963 Yup, that pretty much describes exactly what we're seeing. I think the simplest fix would be to add a parameter to the , and tags, something like remove="true", that when the message has been displayed, it removes it from the list. That way, if the result ends up forwarding rather than redirecting, and the messages get shown and removed, there will be nothing for the store interceptor to store and the messages will be displayed only once. It should be a fairly simple fix and be completely backward compatible with anyone showing the messages multiple times on purpose. Unfortunately I haven't been able to find a good work-around to this and I really don't have the time in my project to not only learn the code well enough to make this change, but then learn maven and enough of the build procedures to integrate it into my project. I would love to hear from ANYONE who has figured a way out of this spiral. Thanks. (*Chris*) - 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: Actionerrors & the Store Interceptor
On Wed, Apr 2, 2008 at 11:17 PM, Al Sutton <[EMAIL PROTECTED]> wrote: > Chris, > > I've used the StoreInterceptor and my opinion is that it just isn't > flexible enough to use. > > To illustrate the point, consider try following; > > 1) You have a View Action which displays all of the data of a specific > type, which uses the StoreInterceptor in retrieve in order to show > confirmation messages from an Update action. > > 2) You have an Edit Action which sends the user to edit.jsp via the > dispatcher result type. edit.jsp has a menu taking the user to other places > in the app. > > 3) You have an Update Action which is called by submitting a form on > edit.jsp, this can return the user to edit.jsp using the dispatcher if there > is a problem with the form data, or it can take the user to the View Action > via a redirect if everything is OK. The Update Action uses the > StoreInterceptor in STORE mode in order to send a confirmation back to the > View Action. > > Now, if the user gets to the edit stage submits the form, but has made a > mistake which sends them back to edit.jsp, clicks on the menu to go to > another action they end up seeing the error message twice, once when the get > redirected back to edit.jsp from the UpdateAction, and a second time when > they click on any of the links from the menu on edit.jsp. > > If you want to track the resolution of this, you may want to look at the > JIRA issue I raised about 10 months ago... > https://issues.apache.org/struts/browse/WW-1963 > Yup, that pretty much describes exactly what we're seeing. I think the simplest fix would be to add a parameter to the , and tags, something like remove="true", that when the message has been displayed, it removes it from the list. That way, if the result ends up forwarding rather than redirecting, and the messages get shown and removed, there will be nothing for the store interceptor to store and the messages will be displayed only once. It should be a fairly simple fix and be completely backward compatible with anyone showing the messages multiple times on purpose. Unfortunately I haven't been able to find a good work-around to this and I really don't have the time in my project to not only learn the code well enough to make this change, but then learn maven and enough of the build procedures to integrate it into my project. I would love to hear from ANYONE who has figured a way out of this spiral. Thanks. (*Chris*) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Actionerrors & the Store Interceptor
Chris, I've used the StoreInterceptor and my opinion is that it just isn't flexible enough to use. To illustrate the point, consider try following; 1) You have a View Action which displays all of the data of a specific type, which uses the StoreInterceptor in retrieve in order to show confirmation messages from an Update action. 2) You have an Edit Action which sends the user to edit.jsp via the dispatcher result type. edit.jsp has a menu taking the user to other places in the app. 3) You have an Update Action which is called by submitting a form on edit.jsp, this can return the user to edit.jsp using the dispatcher if there is a problem with the form data, or it can take the user to the View Action via a redirect if everything is OK. The Update Action uses the StoreInterceptor in STORE mode in order to send a confirmation back to the View Action. Now, if the user gets to the edit stage submits the form, but has made a mistake which sends them back to edit.jsp, clicks on the menu to go to another action they end up seeing the error message twice, once when the get redirected back to edit.jsp from the UpdateAction, and a second time when they click on any of the links from the menu on edit.jsp. If you want to track the resolution of this, you may want to look at the JIRA issue I raised about 10 months ago... https://issues.apache.org/struts/browse/WW-1963 Al. - Original Message - From: "Chris Pratt" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" Sent: Wednesday, April 02, 2008 10:55 PM Subject: Re: Actionerrors & the Store Interceptor Sorry Lucas, I'm still not seeing how that will help differentiate between which result's need the messages collected and which don't? And I have to agree with Laurie, that I don't understand the difference between the store interceptor and what you're proposing. (*Chris*) On Wed, Apr 2, 2008 at 2:47 PM, Lukasz Lenart <[EMAIL PROTECTED]> wrote: > Umm, that's what the Store Interceptor is. Not exactly, you have to specify for which action store the messages, and for which retrieve them back. There is no magic, everything hand coded ;-) Regards -- Lukasz http://www.linkedin.com/in/lukaszlenart - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Actionerrors & the Store Interceptor
Sorry Lucas, I'm still not seeing how that will help differentiate between which result's need the messages collected and which don't? And I have to agree with Laurie, that I don't understand the difference between the store interceptor and what you're proposing. (*Chris*) On Wed, Apr 2, 2008 at 2:47 PM, Lukasz Lenart <[EMAIL PROTECTED]> wrote: > > Umm, that's what the Store Interceptor is. > > Not exactly, you have to specify for which action store the messages, > and for which retrieve them back. There is no magic, everything hand > coded ;-) > > > > Regards > -- > Lukasz > > http://www.linkedin.com/in/lukaszlenart > > - > > > 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: Actionerrors & the Store Interceptor
> Umm, that's what the Store Interceptor is. Not exactly, you have to specify for which action store the messages, and for which retrieve them back. There is no magic, everything hand coded ;-) Regards -- Lukasz http://www.linkedin.com/in/lukaszlenart - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Actionerrors & the Store Interceptor
Thanks Laurie, any ideas on the original problem? (*Chris*) On Wed, Apr 2, 2008 at 2:19 PM, Laurie Harper <[EMAIL PROTECTED]> wrote: > Lukasz Lenart wrote: > > > Hi, > > > > I think the best solution is to develop two Interceptors, one will run > > after action invocation and will store messages in session or some > > other objects from given request key. And second one, which will be > > run before action invocation, that will retrieve such stored messages > > from session and put them in to the request. > > > > Umm, that's what the Store Interceptor is. > > > > > We have some similar solution but for Struts1. We subclassed > > DispatchAction and after invocking execute() method we storing in > > session messaged from given request key. And before next execute(), we > > are checking such key in session and retrieving them back to the > > request. > > > > I thought Struts1 handled that automatically, but ok, if what you have > works... > > L. > > > > > - > 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: Actionerrors & the Store Interceptor
Lukasz Lenart wrote: Hi, I think the best solution is to develop two Interceptors, one will run after action invocation and will store messages in session or some other objects from given request key. And second one, which will be run before action invocation, that will retrieve such stored messages from session and put them in to the request. Umm, that's what the Store Interceptor is. We have some similar solution but for Struts1. We subclassed DispatchAction and after invocking execute() method we storing in session messaged from given request key. And before next execute(), we are checking such key in session and retrieving them back to the request. I thought Struts1 handled that automatically, but ok, if what you have works... L. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Actionerrors & the Store Interceptor
Hi, I think the best solution is to develop two Interceptors, one will run after action invocation and will store messages in session or some other objects from given request key. And second one, which will be run before action invocation, that will retrieve such stored messages from session and put them in to the request. We have some similar solution but for Struts1. We subclassed DispatchAction and after invocking execute() method we storing in session messaged from given request key. And before next execute(), we are checking such key in session and retrieving them back to the request. Regards -- Lukasz http://www.linkedin.com/in/lukaszlenart - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Actionerrors & the Store Interceptor
We're having a problem configuring the system and, since this seems like a common problem, we're hoping someone has found a solution. We have a bunch of actions that can't be run twice, so we're using the redirect-action result type to make sure a refresh doesn't accidentally resubmit the request. We also need to give the user a pat on the back and let them know that things went well, so we're setting an ActionMessage and using the store interceptor to pass the message to the redirected page. At this point everything's working great. The problem comes in when an error occurs. At that point, we put register an ActionError and forward the user back to the page they were on to correct their error. The page displays properly, including the error message and everything looks fine, until... The next time you hit a page using the store interceptor in RETRIEVE mode, you get the ActionError display since the tag doesn't seem to clear the messages once they are displayed. Redirecting instead of forwarding back to the page wouldn't help since the store interceptor is already in STORE mode, it seems like the struts tags should remove the messages once displayed so that they wouldn't be picked up by the interceptor. Is there a way to handle this cleanly? Thanks. (*Chris*) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
