I don't fully understand what your ICallback does and where in the work flow it is activated -

My solution is to design pages that always work, thus, keep the minimum necessary in the Visit (eg current logged in user-id) - the rest on the client -

some examples:
- a direct link should use parameters which indicate the whole state it leeds to - - a form contains hidden fields which contain the current application state ( from a user's view-point).
and so on...

Hope that helps,
Ron



Andreas Bulling wrote:
Hi folks,

I have a problem with the user login session in Tapestry
and my custom ICallback and I would like to hear about
your best-practice solutions again ;-)

The problem is that if the user session gets invalidated due
to a timeout for example and the user logs in again I get
an exception on the previously visited page because my custom
ICallback doesn't work with pages where for example a database
record needs to be read before the page gets displayed.

Does someone know how to fix this? Storing the record id
in the visit object (I'm not using ASOs so far, perhaps I
should instead of the "old" visit object) should work
but is that the best-practice solution?

Thanks,
  Andreas

---------------------------------------------------------------------
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