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]
