We use a serialization strategy that zips the serialized form and base64
encodes it. We're yet to see a performance issue with the solution. The
issue with persisting each field in separate parameter is obviously that of
the number of such fields you are able to persist.
----- Original Message -----
From: "Dmitry Shyshkin" <[EMAIL PROTECTED]>
To: "Tapestry users" <users@tapestry.apache.org>
Sent: Monday, May 05, 2008 4:48 AM
Subject: Re: T5: Persistence pains
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]