It is possible, I implemented my own persistence strategy which uses
DataSqueezer and it was pretty straightforward. You'll need a persistence scope
as well - look at the Form persistence in the wiki to see how you should wire
things together. This "squeeze" strategy combined with the HibernateS
On 9/19/06, Martin Strand <[EMAIL PROTECTED]> wrote:
The client persistence strategy doesn't use DataSqueezer:
https://issues.apache.org/jira/browse/TAPESTRY-738
That's unfortunate. I suppose one could persist them yourself using
hidden fields, at least in simple cases. I just assumed that c
The client persistence strategy doesn't use DataSqueezer:
https://issues.apache.org/jira/browse/TAPESTRY-738
On Tue, 19 Sep 2006 01:53:43 +0200, Sam Gendler <[EMAIL PROTECTED]> wrote:
> Do a search in documentation for 'DataSqueezer.' That should show you
> how to build service objects which kno
Do a search in documentation for 'DataSqueezer.' That should show you
how to build service objects which know how to automatically persist
classes via an id and re-instantiate them later, without any manual
intervention from you. Anytime Tap has to persist an object in a URL,
cookie, or form data
Thanks for the advice Martin. Seems to have fixed the problem however
I'll need to do some testing to make sure it's all gone.
Martin Strand wrote:
Sounds like you have rather large persistent properties.
1. You can try @Persist("client:page") to forget properties when the client
moves to ano
Sounds like you have rather large persistent properties.
1. You can try @Persist("client:page") to forget properties when the client
moves to another page so they don't add up to 15k URLs. :)
2. If you don't really need @Persist("client") you can try @Persist("session")
instead
3. Or, you can
