Variables: Session vs. Client vs. Cookie

Yes, unquestionably, if the ability to save the incomplete session is sufficiently important, you can serialize the data to some database-table of your own devising, much as CF itself will do.  You can code your application so that it, as they say, "freezes" and "thaws" the necessary data each time to your own data-store.  You can even put that business into a nice CFC-routine.  It's really just a question of how disruptive that would be, how much work that would be, what the "cost/benefit analysis" would be.  It might, of course, be "a huge win."

In essence, you would remember the user-identity, a timestamp, maybe even a version number, the complete/incomplete status, the permanent identity of the place where the finished record was ultimately filed when it was finally declared complete, and a BLOB-field containing the serialized data itself.  You could, if you so chose, provide the ability to keep an arbitrary number of works-in-progress.  You could write JavaScript to do "auto-save."

Simply save the cfid, cftoken of the visitor in a cookie,

when he starts the multistep program create a record from which one column would be "completed"

so until the visitor has completed the progress it will stay in the "incomplete" status..

if he returns after the session has ended he will be able to finish his job...

Reviewing this situation, I advise simply "increase the timeout."  Also, educate the users.  Advise them, somewhere on the screen, that a single editing session will time-out after 30 minutes (or whatever) of inactivity.  I've also seen sites that use JavaScript to display a reminder, make noise etc when they detect inactivity on the client side.

It isn't unreasonable for an edit-session to time out.  You're simply wanting to make sure that it does not inconvenience users who have become momentarily distracted by the presence of other alligators.   A note, and maybe a little JavaScript wake-up call (Zzzzzzzzz... huh? oh yeah...) might be just what the doctor ordered.  Making massive and disruptive rewrites to "an intricate application that works" is not.

A cookie is not an appropriate mechanism for this purpose.

Options include:

1. In your application, provide a way for people who know that they're going to be "distracted" to save their work and then come back to it.
2. Add a small JavaScript loop that, on a timer, periodically "pings" the server just to keep the session data alive.
3. Add an auto-reply filter on your e-mail system so that, whenever users complain, it auto-replies to tell them that it's their fault not yours.


4. Increase the session time-out interval on the server.

This is one of those things that, quite frankly, can demand far more time and re-work than it will ever deserve.  There comes a time when you simply have to tell people, "that's just the way that this application works.  Come to a good stopping place before you take off doing something else."  Given that the application works well just the way that it is, this is a compelling rationale not to rip the thing apart just for a dubious "fee-chur."

You could use Session variables but also a timer that periodically

pings the server to keep the session alive (for example you can use

jQuery to ping the server asynchronously). The timer should be used

only on the pages where the actual data is entered otherwise your

sessions will not expire as long as the user has a page open.

Depending on the size of your data you can also store the info in a

cookie (maximum practical length for cookies seem to be at around 4K

so if your data is larger then that it will not work).

Mack