The wiki page does look useful, but could be written more clearly. I'll
try to find time to update it.
The tomahawk saveState tag saves data in the *jsf view*. Therefore, that
data lasts as long as the user is on the same view, and is then
discarded. However when a JSF postback navigates to another page, the
new page can itself use a saveState tag to "grab" the data from the
previous view into itself, so data can be kept alive across multiple pages.
This is quite different from either "request" or "session" scope, and is
quite useful.
If you are using client-side-state-saving for the jsf view then of
course anything saved into the view using <saveState> is sent across the
network to the browser, like the rest of the view. So don't add anything
too big.
If you are using server-side-state-saving, then the object is serialized
and saved into a special http-session attribute along with the rest of
the view. But it will be discarded automatically along with the rest of
the view data when the user navigates to a different page.
Regards,
Simon
[EMAIL PROTECTED] schrieb:
There's some info in the wiki page
http://wiki.apache.org/myfaces/SaveState
I think generally though you would use the saveState instead of the
session. You can put a managed bean in a saveState tag and it will be
saved in the page, probably in the viewState... I used it a while ago on
a request bean but eventually we switched that to a session bean for
other reasons and no longer needed the saveState tags.
-----Original Message-----
From: jhomuth [mailto:[EMAIL PROTECTED]
Sent: mercredi 17 septembre 2008 12:05
To: users@myfaces.apache.org; [EMAIL PROTECTED]
Subject: SaveState Session or Not ?
Hello List,
I've a small question. We need to save some Data over more than one site
but not for the whole session. That's why we wanna use the <x:saveState>
Tag. But we can't find any documentation about the concept of saveState
the tag. What we need to know is will the data be saved in the session
until we discard it or will it passed again at any request. And are
there any design traps we could fall in?.
Thx for suggestions
