The problem in "client" strategy that it used Serializable mechanism of
jvm. Of cause it produce a lot of data (not getting in mind that most
domain objects are not Serializable). I use own persistent strategy
called 'parameter'. It is similar to "client" with follow exceptions.
* It uses ValueEncoder to convert from Object to String and from
String to Object. It save a lot of space, because for domain
object only it id is persistent, which is rarely longer than 6
characters.
* It persist each field in separate parameters (when "client"
persist all data in parameter t:ac) . In this way it is similar to
activation context's friendly url behavior. User see somethings
like this http://somewhere.com/page?user=123&order=12&item=5
With help of this strategy I persist data between request to the same
page. It solves both: problem with multiple browser tabs and problem
with too many persistent fields in session.
Ivan Dubrov wrote:
Right. Most annoying things for us about “session” and “flash” scopes
was that they don’t work in several tabs. And “client” can’t hold too
much data.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
