Re: PHP Form split into many pages
Posted: Thu Oct 02, 2008 11:31 am
Sounds good to me.
A community of PHP developers offering assistance, advice, discussion, and friendship.
http://forums.devnetwork.net/
VladSun wrote:
The last thing we have both to agree with is that some of the values submitted in a step can strongly depend on a values submitted in a previous step (that's is usually so for wizards). So we can't really (or it will be too dificult to) validate all of the data in the final step. We should keep track on the validity of the data on every step.
To be frank with you, this exactly how I thought I'll tackle this problem but then came the question of network traffic and also the response time issue with this approach. So I was suggested by wise men around mejmut wrote:My 2 cents.
When I make wizards I usually store all data on each step. This is I have column in db wich shows which step I am at and one that shows if uncompleted , uncofirmed, completed etc..which shows wich are actually really finished. This is needed and good to have most of the time for marketing/stats reasons, especially if it comes to orders but I think for anything else..just as well. You need to know on which steps people have trouble with so you possibly fix it or assist them, log each error of customers so you see where they have most trouble on etc etc. If you don't need those, simple cronjob can purge 1day old entries and you leave with only completed processes. So besides current_step column you'll have reload_step column. Reload step is used if customer want to go back to some step - when done there you'll know where to get him back to based on current_step. Then you have no reall problem with uploaded files and all, regardless on wich step those are required.
On your scenario that you don't want to store each and every data..... well it is a total must that you need to validate each step's entered data on each step. And if some choice in one step invalidates something else that already entered in another there should be text explaining that and customer not unexpectingly loosing data.
What will you do if file upload was not in last step? You'll still need some temporary solution for storing data.
I would do it this way (Linux):Rabi wrote: Only piece of stumbling block is that file upload option has to be on 3rd page and not on the last page. This is something that is giving me tough time to decide how to do this. I was thinking of uploading the file on server file system when user moves to NEXT page. In case user decided to come back and upload different file, delete old file from server (We'll have old file name in the serialized var) before uploading new file. What do you think of this approach.
Code: Select all
find /temp_upload -type f -cmin +1440 -deleteVladSun wrote:I would do it this way (Linux):Rabi wrote: Only piece of stumbling block is that file upload option has to be on 3rd page and not on the last page. This is something that is giving me tough time to decide how to do this. I was thinking of uploading the file on server file system when user moves to NEXT page. In case user decided to come back and upload different file, delete old file from server (We'll have old file name in the serialized var) before uploading new file. What do you think of this approach.
- create a directory /temp_upload with 1700 permissions;
- in php.ini set upload_tmp_dir to /temp_upload;
- permit user to upload any number of files in any step of your wizard;
- in the next step don't use move_uploaded_file() (which will leave the file in your temp directory with a name $_FILES['HMTL_file_input_name']['tmp_name']);
- encrypt the $_FILES['HMTL_file_input_name']['tmp_name'] string (due to security reasons) and pass it to the next step like you do with an ordinary form input;
- in the last step, if everything is OK iterate through your saved file names, decrypt them and use move_uploaded_file() to copy;
For cleaning files submitted by "never finished" wizards (that is not finished in 1 day e.g.) use a daily cronjob:Code: Select all
find /temp_upload -type f -cmin +1440 -delete