| 
	
 | 
 Posted by Jack Jackson on 06/17/54 11:22 
Thanks everyone. I take the point of Andre, but believe that the depth  
and sensitivity of the data require it be stored server side. I think  
that Richard and Mark have put their fingers on it - it's gotta be  
cookie based. Someone on the IRC suggested sessions and I think that it  
the way it goes. As for the idea that new users would be sent packing by  
such a ridiculously long form, right on! This is a form to be filled in  
by a client of the company after they've hired to company to provide an  
assessment of ther practices, so they'd expect a long form. But point taken 
 
Thanks everyone for replying so quickly! 
 
I'll come back when I botch the sessions and need help fixing!! 
 
JJ 
 
 
Richard Davey wrote: 
> Hello André, 
>  
> Wednesday, July 27, 2005, 2:22:30 PM, you wrote: 
>  
> AM> That's not a very good idea. Imagine the user gets to the fourth 
> AM> form and gets a cup of coffee, or goes out to lunch. By the time 
> AM> he gets to the computer he might have lost the session, thus 
> AM> having data on your DB that is wasting space. 
>  
> AM> And what if the user closes the browser window? :) 
>  
> All of those things are unavoidable no matter what technique you use 
> :) 
>  
> I've seen multi-page forms with a "Finish this later" option that 
> issues a cookie to your browser, allowing you to visit the site at any 
> (realistic) point in the future and carry on. In which cases the 
> part-filled contents must already be in a database somewhere. This 
> isn't a bad thing imho, it's a nice touch. 
>  
> Of course it's prone to the usual "browser doesn't accept cookies / 
> browser deletes cookies" syndrome though. 
>  
> If you don't want to pass the form values across in a hidden manner 
> (and I don't blame you) then it's either dump it all in a session and 
> hope it doesn't time-out, or dump it into a database, issue the 
> visitor some link to that entry (cookie, session var) and again hope 
> they don't time out. 
>  
> The only real difference being the DB option will need purging to get 
> rid of incomplete forms > X days old. But that in itself could prove a 
> useful statistic for reports. Unless you're dealing with thousands of 
> sign-ups an hour, I don't see any issue with this option. 
>  
> Another technique might be the following - rethink how your forms 
> work. Exactly what is it you're collecting data about? If it's part of 
> a long sign-up process then you could consider changing the process 
> around a bit - so that the VERY first thing the user does is create a 
> temporary account on your site (call them "incomplete users"). So you 
> grab some method of login + authentication details from them. Then the 
> form pages following this can all be saved to a DB and linked to that 
> user. 
>  
> So, as long as they complete this first step, they can always come 
> back and finish the job off - whenever they want, avoiding cookie and 
> session time-out issues. 
>  
> This won't work for all forms of course, it depends what the nature of 
> the process is, but it's certainly an option. 
>  
> Best regards, 
>  
> Richard Davey
 
  
Navigation:
[Reply to this message] 
 |