Multipart forms are the solution you need. Here are the reasons why:
1) You can set the length of time that the session cookie will live (I've changed it to a week for the "Remember Me" feature of my website, works nicely)
2) if users are disconnecting, and not all information is being processed, then you can use register_shutdown_function() to catch this problem (i.e., if mid-processing, prior to database write, the user disconnects, the shutdown function will do any necessary cleanup). All you will need to do is have a flag variable that you set when necessary tasks have been completed. So, after form processing, set it to 1, after database write to 2, etc. The shutdown function would check this flag variable and then do the next steps if necessary.
3) even if they switch off the PC and try to start from scratch, all you need to do is use sessions and I would recommend using the HTML_QuickForm package from PEAR (pear.php.net) as the freeze() method will be VERY useful. Basically, when a field is complete and shouldn't be changed, you freeze it and it will display the value for the user, but not allow it to be changed. There is a large userbase for QuickForm and many people using it in multi-part forms who can answer your questions easily.
4) in the final review process, if you require the user to submit each sub-section as "OK" there will be no chance of losing more than a few minutes of work. In other words, the final review should also be multi-page, matching the original form. The user will understand this. Paper forms have more than one page, and you have to flip them back and forth, so if you model it that way, no one will have a real problem, even really computer-illiterate folks :).
Regards, Greg -- phpDoocumentor http://www.phpdoc.org
Petre Agenbag wrote:
Hi Shiva Appreciate your input. Wrt the spanning of the form, I think, in my situation, it would actually make things worse... You see, my suspicion is that most of the users who are experiencing problems, have very bad connections, many complain that they lose connectivity while they are busy with the form ( it takes them maybe 30 min or so to fill out the entire form ( they basically transfer the data off paper forms they have filled out earlier while "on-site", so it's not really alot of data, but there are a lot of fields...) So, my fear with this approach is that they will maybe get past the first part of the form, submit that OK, then start getting trouble with subsequent parts, leaving me with a whole lot of partial entries in the DB., and how do I get them to "resume" at a a later stage? You don't understand the mindset of these people, when something goes wrong, they'll switch off their PC's and try to start from scratch, so it's going to be difficult to try and get them to understand the concept of multi-part forms... I shudder to even think what will happen, or worse, how I will be able to allow them to make corrections on a certain part of the form once they have submit it. And sometimes, to their defense, it's not them that want to change the details on the form, but the subject of the form who has decided to change their name etc...
I'm not ditching this idea, I will definitely give it some more thought, it's just at this moment, my mind is running through my original idea of PDF forms trying to evaluate it.
Each method will have it's pro's and cons, and I'll have to go and weigh them. I must add, I don't see "effort" as a con for a particular solution, as long as I know it will solve the problem without adding other cons...
Thanks again, will take it up with you again ( need some more input on this PDF thing to get some balanced views)
PS, if you have experience with using this method, I would appreciate it if you could let me have your "field notes" and how successfull it's working for you. You see, the main thing here is that I need to KNOW when someone who says they have submitted something actually have, and that they are not trying their luck...
On Tue, 2003-07-01 at 13:43, Shivanischal A wrote:
hi,
seems u have complicated task on hand mate. cant u simply consider span the user input over multiple pages? i mean using 2 or more form on different pages instead of a single form on one single page. if this cant be done, we'll think of other measures. but this is by far the most simple method
-shiva
"Petre Agenbag" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
Hi List
OK, firstly, sorry if this has been on the list before...
What I'd like to do is something like this:
I currently have an app that takes user input via a normal html form, and then pops the content into mysql.
The problem is that lots of user complain that the submit times out due to slow/bad connections, and hence the data gets lost.
What I was hoping to do now, was to somehow create a PDF form from the current html form ( should generate itself on the fly ) , the PDF form will obviously need to be downloaded to the user's PC, and will be unique for each time they use the system, ie, I don't want to just give them a blank template PDF, some of the values need to be "auto-completed" and inserted into the form as "read-only", as well as a couple of "hidden" fields with identifying values so I can know where to pop it into the db.
The idea is that the user will now come to the point where he would usually have filled in the html form, but instead, the app must autogenerate a PDF with some values auto-completed and/or hidden, and the user then downloads the pdf to his/her PC, where they continue to fill out the pdf form.
Then, on completetion, I'd like to investigate several delivery mechanisms, arguably, the easiest way for the users ( who are mostly techno-peasants), is to simply e-mail the pdf as an attachment to me), but then I will either have to create an auto-parser for the email (prolly difficult and prone to problems with making sure the attachment is correct etc), or I will have to then manually process the attachments.
Either way, I would need to "feed" the pdf to my app, where the form/hidden variables would need to be harvested from the form, and noly then (after validation), be entered into the db.
So, simple concept, but I'm sure many pitfalls, the least being probably that I have never done this, and don't know where to start, or even if it's possible/advisable to follow this route.
Hence my post here...
-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
