It is six of one, half dozen of the other. Except. :)
Once you write the squeezer implemenation and register it, you no longer
have to think about it.
You reduced the duplicity in your code. :)
Robert
Patrick Casey wrote:
His problem as I understand it is a bit less easily resolved than
that. The default data squeezer has some custom code for dealing with
primitives and the "pseudo-primitive" string class. When it runs into an
arbitrary object though, it just serializes it into a byte[] then runs
base64 encoding over it to produce a legal string.
With a decent sized object, this serialized object is too big for a
URL which has a maximum length. So you can't use the default squeezer
approach to push the object out and get it back.
One approach that Roger suggested was to write (and register) a
custom squeezer which "squeezed" a DB object down to its className/key
combination and then reloaded it from persistent storage during the
"unsqueeze" operation. His approach sounds like it'd work fine to me, but
I've generally gone the less sophisticated approach myself and just
boostrapped my objects in the listeners themselves.
Six of one, half dozen of the other I suppose,
--- Pat
-----Original Message-----
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Raul Raja Martinez
Sent: Wednesday, January 18, 2006 10:06 AM
To: tapestry-user@jakarta.apache.org
Subject: Re: ActionLink and DirectLink
Do you mean the DataSqueezer?
http://wiki.apache.org/jakarta-tapestry/DataSqueezer
Martin Strand wrote:
I often find myself doing this, stuffing an object id into a DirectLink
or storing an object id in a persistent page property and then
recreating the object in pageBeginRender. Can't Tapestry handle this
conversion instead? I'm thinking of something like the "converter"
parameter in the For component.
On Wed, 18 Jan 2006 18:15:24 +0100, Patrick Casey
<[EMAIL PROTECTED]> wrote:
A fairly standard approach is to not send the object out on the
directlink, but instead send out some sort of uniquely identifiable
key and
the pull the object back out of persistent storage as the first
operation in
your direct link.
If you're talking about DB objects, then putting the unique key on
the outbound URL and then reloading it in the listener is certainly the
easiest approach (although not without security implications because
you're
opening a door for the outside world into your key structure).
Alternately, if it's something that doesn't have a "natural"
storage
mode or key, you can just wrap it in an object with a key then stuff
it in a
server-side linkedhashmap that you then store in the client session.
The
reason you probably want to use a linked hash map is to "forget" about
objects you stuffed in there a while ago so that you don't end up with
2,000
objects cluttering up server side memory when the user is only likely
to use
the most recent 5 or so of them. In practice, I've found a page memory
of 10
is almost always big enough.
--- Pat
-----Original Message-----
From: Stijn Christiaens [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 18, 2006 3:50 AM
To: Tapestry users
Subject: ActionLink and DirectLink
Hello everybody,
previously I used ActionLink to do my dirty work, but it seems that
this
is not such a safe approach. In transferring to DirectLink I am a
little
bit unsure about how to continue.
I use my DirectLink with a listener and parameters. Unfortunately, the
parameter Object I have to pass is too big to be serialized in the URL
(the DirectLink does nothing because the URL is too long). So I
probably
have to pass some kind of key (no database key as it is an Object in
edit, so not saved yet and not to be saved yet either) as parameter.
Where do I store the Object that is associated with this key?
Do I place it on the Component or somewhere on something I can access
using IRequestCycle?
Thanks in advance!
Ciao,
Stijn
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
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]
