Personally, I don't like the idea of the framework itself relying on heavy use of the HttpSession and "hiding" it in this way. There are many cases when you want to avoid use of HttpSession for scalability reasons (there's that word ;) ). I like how currently WebWork/Struts 2.0 makes it difficult to get to the raw HttpServletRequest or HttpSession... it takes an intentional act on the part of the developer to use either. By introducing an api like this, which I am guessing would live off ActionSupport, we are making it very easy to abuse a feature that arguably should be tightly controlled. This is the main reason we went with cookies as the medium for transistional storage of our Flash-scope messages/errors.
That said, I might be missing the problem you are trying to solve. Is it just about abstraction of the HttpSession? Supporting Workflows? We originally went down the generic route that you are considering and then scaled back the design to handle just messages/errors because we couldn't really find any pressing need for other uses outside of workflows which we decided to handle separately. It seems to me that this solution is aimed more at the Workflow-type scenario... in which case I think it is missing the mark. Doing Workflow in a web application involves more than just conversational state, it is a complex problem and deserves a first-class solution ala Spring WebFlow and Struts Workflow. - Chris Mathews http://www.javaranch.com -----Original Message----- From: Michael Jouravlev [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 29, 2006 6:03 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. So you write out messages to the cookie? So this is limited to messages only? I am about to create a more generic storage, so cookies won't work. Also, sometime around Struts 1.2.4 or 1.2.6 the new way of handling messages was introduced. It is kinda of Flash/Conversation/Click scope (I will be calling it Conversation scope since getConversation() looks better for me than getClick() ), but messages are not removed until they are accessed, so in theory they can live longer than one roundtrip. I was thinking about storing Conversation scope in the session, but this approach is limited to only one instance of an object, so it is more like having a session-scoped object without benefits of its longer life. And if session expires, Conversation object would expire too, very unlike of request object (now I am thinking... Now I get the point why session is accessed from request, not vice versa: because request object actually can live longer, it does not expire.) Antonio's idea of storing Conversation Scope (CS) in Request works much better. I am thinking about something like this now: First, HttpRequest should be cast something like HttpStrutsRequest, that has getConversation() method. Then a user does the following: conversation.set("myobj", mybean); What happens behind the scenes: refMyObj = request.set("myobj", mybean); Map convScope = request.get(CONV_SCOPE); if (convScope==null) { convScope = new HashMap(); request.set(CONV_SCOPE, convScope); } convScope.set("myObj", refMyObj); CONV_SCOPE will be a well-known constant. So for all scope users like Struts tags or JSTL, CS is nothing more than good old Request scope. On redirect CONV_SCOPE map is stored in the session, then on next request it is pulled out the session and Request object is filled with values from CS. Pretty simple I'd say. As Antonio pointed out earlier, a cookie should be used to store the CS, so a user could open several windows and have separate CS objects, just like several Request objects. On 8/29/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > 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]
