How to handle multi-page forms
I actually have seen very few multi-page forms lately, but I became very curious about the issue as I continued through my XHTML book (more of a review - I've decided to go back and actually read books about the languages I have learned online). If you create a form that spans over multiple pages, such as, let's say, some sort of registration form. Clearly this method would not be advantageous, but this is simply to create the hypothetical situation.
Let's say the first page requires the user specify their first name and email address. The click submit, which takes them to the next page where they will enter their desired username, password, etc. All of this data is to be inserted into a MySQL database when the registration is complete. Anywho, when the visitor moves on to the second page, I have always been taught to enter the first name and email field values into a hidden field to hold on to and process with the rest of the values once the form is complete. However, is it a bad idea to go ahead and create a new row in the table with the first name and email values, and then when the second step is complete (username, password, etc) to update the row with the rest of the information? Are there any reasons why one should absolutely not use this method?
Are there any reasons why one method (hidden fields) or the other (updating the MySQL row as the data is available) is clearly better or worse?
Again, this is simply a hypothetical situation. I am not actually doing this; I simply was curious to find out what the better solution is.
Kurtis
kb posted this at 02:08 — 19th July 2007.
He has: 1,380 posts
Joined: Feb 2002
Well, there's a few answers.
The quick and easy one, in my mind, is that updating the MySQL as you go would be a better choice, if only because you don't have to track numerous variables across many pages. Using sessions or cookies for something like that would be kind of overkill, I think, unless you're talking about a shopping cart. And with the speed of MySQL, no-one would ever know.
As for using "hidden" fields, as opposed to PHP variables... that's generally a terrible idea for anything involving personal information. Use them to keep track of what's being submitted if you want, but not the data itself.
The ultimate answer is....
Don't do it.
Either create a one-page form, or create a dynamic page. If you create a dynamic page that uses AJAX, you then have the ability to process as you go (aka insert/update db rows)... but also without the page refreshes. Or, you could have a one-page form with a bunch of portions hidden until certain fields or parameters are selected/filled out.
I didn't directly answer your question... but knowing more has never killed anyone, I guess...
kazimmerman posted this at 02:13 — 19th July 2007.
He has: 698 posts
Joined: Jul 2005
That's actually why I proposed simply using the first name and email address as the information being stored. I can see the email address being personal, but a first name can not directly identify anyone (except maybe Prince or Cher...
).
Anywho, it's simply a hypothetical situation, and perhaps, not even worth being discussed, but it was an event that popped in my head.
Kurtis
pr0gr4mm3r posted this at 04:40 — 19th July 2007.
He has: 1,502 posts
Joined: Sep 2006
When I have to do it, I use the $_SESSION variable. Every time a page is submitted, I use the array_merge() function to merge $_POST with $_SESSION['form']. Then, when the last page is submitted, all data is inserted at once. I don't like the idea of inserting the data into the DB page-by-page because you always have the people that bail out before submitting the last page and you have to worry about cleaning out half-completed forms.
Also, if data is validated on every page, remember to validate all data at the end even if it was validated before on previous pages.
Want to join the discussion? Create an account or log in if you already have one. Joining is fast, free and painless! We’ll even whisk you back here when you’ve finished.