[Catalyst] session issue

Daniel Hulme st at istic.org
Thu May 24 08:59:10 GMT 2007


On Thu, May 24, 2007 at 05:33:16PM +1000, Gaurav Talwar wrote:
> i am working on a website using catalyst. Users are required to fill
> some forms which are 4-5 pages long. While filling the form he may opt
> to go to the previous page to edit details he has previously filled.if
> he goes back to the previous page I need to show him all his details
> he chose/filled on the previous page.
> 
> I am using session to store all his details he is filling in the form.
> When he goes back to the previous pages, i take the information from
> the session and i fill them in the pages.  Now the problem is that if
> users opens two forms together and fills some data and then goes back
> to previous page, the session shows him the data (he filled in the
> second form )in the first form.
> 
> I know the problem is that they are using same session. But how to
> avoid this? Any help will be highly appreciated!

Whether this is a good idea I can't say, but it is an idea nonetheless.

In the session, instead of just storing an object (hash, list, whatever)
with the details, store a hash from a random (or sequential) ID to the
details object. Every time the user enters the form, generate a new ID
and put it in a hidden element on the form. When you get some form data,
use the ID to decide where in the session to put it, and when you
generate the next page of the form, send the same ID in another hidden
element.

This way, the user can open pages from a form in different tabs and have
them all edit the same details. He can also open another form (from a
different entry point) in another tab, or even in the same window by
pressing 'back' a few times and clicking a different link, and have
different details. The first details are still in the session so he can
go back to the first set of forms and finish from where he left off.

Of course, if your forms are editing some object that is stored in your
database, it might be a good idea to make the ID depend only on the
internal ID of the thing the user is editing: that way, if he clicks
'back' several times and then opens the form from the start to edit the
same object he was editing before, it uses the same ID rather than a new
one. It may or may not make sense for you to do this.

The other variation is that you could use a GET parameter (or an URI
path argument with the ID) rather than a hidden form element. It
probably interacts better with caches and it is clearer to the user what
is going on if he cares to look. If you have the ID of the object
being edited in the URI anyway, and you have the form ID being the ID of
the object, you don't need to change your templates or URIs at all: just
make sure you use the ID as a hash key for details objects.

-- 
"I tried snorting coke once, but the bubbles went right up my nose and I
knocked the glass over."   -- 'Sordid Confessions of a Teenage Innocent'
http://surreal.istic.org/                              Show, don't tell.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.scsys.co.uk/pipermail/catalyst/attachments/20070524/bddc10ab/attachment.pgp


More information about the Catalyst mailing list