Multi-Step Form Data

[eluser]BrandonDurham[/eluser]
When creating a multi-step form (specifically a form broken up into three steps/pages) is it a bad idea to create a session variable containing the form data to carry it between pages?

I'm working on a form for a CMS where the user can add new albums and all related info (images, tracks, mp3s, etc.) and I've broken it down into three steps. I want them to be able to move freely between all three steps, and this is why I'm interested in adding the info to a session variable instead of filling in hidden form fields with the $_POST data since they may not always land on each step via a POST.

Is this bad form (no pun intended)? Is it unsafe (the whole CMS is protected with user authentication)?

I appreciate any help I can get. Thanks!

[eluser]esra[/eluser]
Quentin Zervaas posted a tutorial for creating multi-part form wizards a few years ago. It was intended for PostgresSQL, but you should be able to adapt the approach to CI's abstraction layer. The link is below:

http://www.phpriot.com/d/articles/php/ap...page4.html

[eluser]mironcho[/eluser]
By default CI keeps session variables in session cookie (which can be encrypted). Cookie size is restricted to 4kb and if it's encrypted you can store less data (maybe_encrypted('ci_session_data' + 'your_data') < 4kb). So you must keep in mind that you can't store many data in session variables (if you are using default CI session).
For more info - user guide:

http://ellislab.com/codeigniter/user-gui...sions.html

[eluser]BrandonDurham[/eluser]
I'm actually using DB_Session...

[eluser]mironcho[/eluser]
Well, then my post seems to be useless

[eluser]ACSparks[/eluser]
A common approach I have seen to accomplish this is just to pass data between pages in hidden inputs. A surprisingly large number of high profile sites use this technique.

It eliminates alot of the issues with storing form data in the database, mapping that data to a user, and knowing when to expire that data from the table. (If a user does 2 out of 3 steps and stops).

I have used both techniques, and prefer to just use hidden inputs.

[eluser]BrandonDurham[/eluser]
Yeah, but that method fails when you allow the user to navigate between the steps freely because there is often no $_POST.

[eluser]ACSparks[/eluser]
You are right. It makes the assumption that if a user is on Step 3, and wants to jump back to Step 1, then they must fill out Step 2 over again.

For a javascript way of getting around this, check out the Threadless shopping cart. They use the hidden input field method, and use js calls to pass the data backwards between steps.

[eluser]mwmerz[/eluser]
I actually have been searching the forums to find old posts about form processing. Since i've started using code igniter and started reading coding approaches within this community, my code has increased leaps and bounds in professionalism and efficiency. I fully understand many of the methods and theories regarding properly abstracted and written code.

Right now though, as far as forms go, this is my process:
(all using the default load->view parser rather a than templating system)

1. Create generic view for site
2. When calling generic view, i pass a template variable to nest the appropriate view for that method.
3. For a form, load view for step 1, checking to see if session variables are set for the field values, then i have some javascript/dom stuff for field validation. Passing the variables in a session, the user can go through all of the "steps" which all exist in separate methods with separate views. (i.e. Campaign controller manages campaigns. i have a build method which calls the form, i then have a build_process method which acts almost like a controller for the form, if step 2 and 3 aren't complete, it persists the data from step 1 and calls the next appropriate step, if all is complete, and all data is valid, process form into db). But that means every single form i make takes up at least 2 methods. I'm sure i am doubling logic over and over.

While i know it is many times a matter of personal preference, are there guidelines for best practice in setting up forms in an OOP manner? Does anyone have any sample code for form processing? Especially with dom manipulation ruling progressive development, are there best practices for employing dom manipulation within a form? Ie. Radio button with 3 selections, different input types appear based upon appropriate selection?

Thanks, I hope that was clear,

Merzy

[eluser]Jarek Bolo[/eluser]
Hello

If you're not avoiding usage of JS then XAJAX library is very handy with form processing, especially with its build in function getFromValues('form_id').

Recently I wrote an questionnaire which asks client what kind of web site is he/she looking for.
It's here.

Unfortunately it's not in English.
Generally I'm showing first div with &lt;form&gt;, then on submit (using JS function onclick), if there is no bad answers I hide first div and show result in a second div, if client accept it he/she can click yes (Tak in Polish) and questionnaire will be sent via email, and data will be passed again from that hidden form. If client wants to change something then clicks Change (Popraw in Polish), first div with &lt;form&gt; appears again with all data entered and second div is erased.

The only disadvantage is usage of JavaScript, but in my opinion we should rather enforce others to stop not using JavaScript then writing non-JS versions of our websites. But then what about miniOpera and cellphones :/
Echhh...

Hope this will help you.

Jarek Bolo