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]

Reply via email to