Multi-page forms, sessions or hidden fields?

[eluser]Pete Smith[/eluser]
Once again dipping into the well of wisdom here...

So I'm creating a fairly complex order form, and I want to break it up into several pages.

Say for the sake of argument, 3 pages, or 3 steps.

Step 1: Enter your general information (name, address, email, etc)
Step 2: Enter customizing information for the items you're ordering. On this page there will be both textareas and file upload fields (for company logos).
Step 3: Get a total cost, enter CC info and stuff, and place the order.

Obviously I need to carry data forward from steps 1 & 2 to that final step.

I'm trying to ascertain the best way to do that. I could use hidden fields, or I could use sessions. Or maybe there's a 3rd, better option?

My fear with CI Sessions is that 4K limit on the cookie (do any of the 3rd party CI session replacements work around the cookie limit?). At the same time, hidden fields are feeling pretty cumbersome.

Any thoughts/ideas from those who've done something similar?

[eluser]rogierb[/eluser]
I've done the hidden field thing but i'ts a b*tch to code, especially when your users use the back button (and I didn't know CI was around).

After that fine experience I went for an alternative options, a temporary table which stored the session_id and all form data. This allowed for more complex forms and could compensate for all user action.

I also stored a date-time an a cronjob cleans the table of all old form that havn't been posted completely.

[eluser]CI miller[/eluser]
You can create different methods and views for each step also. After one step is completed you make a redirect the new step. You have to store in a server session / database table all the data posted by the user and the indicator of the maximum reached step (in case the user figures out the URL logic and tries to skip some step).

Or you can make one giant form and break it into steps only visually with javascript (use tabs or something similar).

[eluser]optimal[/eluser]
[quote author="rogierb" date="1182859936"]After that fine experience I went for an alternative options, a temporary table which stored the session_id and all form data.[/quote]

That's a good option, or another would be to just use your existing order table for temporary orders, with a new flag column indicating whether or not an order is complete. Similarly, a cron job could purge old, incomplete orders.

[eluser]Rick Jolly[/eluser]
I'd rather not save order info to my database until the order is complete to avoid having to cleanup incomplete orders.

You can store all the info in the session if you use php native sessions ($_SESSION) or use the CI native session library in the wiki.

You would have to cleanup files in the case an order isn't completed though. You could store files in a temporary directory and move them when the order completes. Of course that temporary directory would have to be cleaned of old files (maybe at least a day old to be safe) from time to time, perhaps with cron.

[eluser]esra[/eluser]
Anyone have experience using multipart forms in conjunction with CI transactions? CI does support ADOdb-like transactions for the mysql INNODB and BDB database engines and other database engines. Then you could use multiple queries to handle the form parts with commits and rollbacks to control the failure or success of the various query operations. This is documented to an extent in the user guide. Since the ADOdb approach is used, maybe some ADOdb tutorials exist on the web for handling this sort of thing.

[eluser]liquid_t[/eluser]

I’d rather not save order info to my database until the order is complete to avoid having to cleanup incomplete orders.

(sorry, a bit OT)

I dunno. I know it can be a mess to clean up, but the information within could be valuable...

Completed orders tell you what people bought (obviously), but abandoned carts/orders can tell you what they are window-shopping for. They can potentially tell you what area of the site users are dropping out at. If you do some "dumpster diving" inside your temp-cart table, you might find some interesting trends and patterns, things you would never know (nor be able to capitalize on) if you just waited until after the user pays to capture the order.

Of course, you would probably have to progrma in an effective way of analyzing the contents of the carts and creating useful stats, but it might be worth it.

[eluser]marcoss[/eluser]
You should try OB_Session wich does a good job using the database for data storage. It also performs the clean up for you

Anyway if you can keep the data small, i suggest Cookies + Flash Data (included in OB_Session) and the "read once" method.