We have added support to WebWork 2.2 for "Flash Scope" in a slightly different way...
We support adding Flash-scope Action Messages and Action Errors without resorting to using the HttpSession. In our solution, we actually write out a small Session Cookie by extending ServletRedirectResult and ServletActionRedirectResult provided by WebWork. On an incoming WebWork Interceptor we read this cookie off the request and populate the Action's Action Messages and/or Action Errors if any are found. This has worked very well for us and was ultimately a very easy solution to implement... I have looked at Patrick's FlashScope in Able and saw that he was storing off the entire Action into the HttpSession. Interesting approach but ultimately in the scenario we have encountered in our applications we have really only been looking to provide either a message(s) or error(s) that survive a redirect. Not sure of the scenario where you want the entire Action on the other end... - Chris Mathews http://www.javaranch.com -----Original Message----- From: Michael Jouravlev [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 29, 2006 5:19 PM To: Struts Developers List Subject: Re: [jira] Created: (STR-2939) Provide a conversation scope (syn: Flash scope, dialog scope) object to store data between requests. On 8/29/06, Antonio Petrelli <[EMAIL PROTECTED]> wrote: > Michael Jouravlev (JIRA) ha scritto: > > In addition to standard J2EE scopes (page for JSP, request, session and > > application) provide a new scope object that would hold data between > > requests. Similar facilities in Tapestry and Stripes are called FlashScope, > > Struts 1 will call it as Conversation Scope. > > > > Micheal > I know that's a bit out of "scope", but now I'm guessing if there is > space to incubate Scopes: > http://scopes.sourceforge.net/ > The "flash" scope is called "click" scope: > http://scopes.sourceforge.net/documentation/more-scopes/click-scope.html > I think it could be used among a large set of frameworks, including > Struts 1, Struts 2 and Shale. > What do you think? I need just one scope, so I don't think that bringing in a whole library just for one scope makes sense. Also, your library depends on Java5, while Struts 1 is built on Java 1.4. On the other hand, you already have done the work. Also, your idea of storing Click scope in the request and pushing it to session only between requests is better than mine idea of storing it in the session: less issues with garbage collection and the same ability to have multiple instances of, say, formbeans like with request scope. I have another suggestion: storing data right in the request object instead of having a dedicated scope object. Then, on redirection, pushing appropriate items to the session, using item's names. Thus, the Click scope control object would store names instead of storing objects themselves. This way we would not have to do anything to update the search chain page->request->session->app for Struts tags and JSTL tags. For the tags, Click scope would be just a regular request scope. I would also prefer zero configuration, thus better integration with Struts. Therefore it would be great if you wrote a separate version specifically for Struts with full integration, or I can do it myself, taking your code as the basis. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ********************************************************************** This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. ********************************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
