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]
