You might want to consider using WDDX to move that stuff back and forth. 
I.e. instead of having lots of hidden fields to move lots of variables 
to the next form, have one hidden field with a huge WDDX packet 
containing a stucture which holds all of your arrays and simple 
variables.

ISTR Spectra uses this idea so I would guess it's been tested with large 
volumes of data.

Cheers,   Andy.

Keith Young wrote:
> Hey all,
> 
> Have any of you handled very complex, multi-page forms before?
> 
> I am setting up a form, it is 4 pages long.  The first two pages are 
> very simple, and the remaining two are rather complex. For example, 
> pages 3 and 4 both have default rows that are always present, that may 
> or may not have data filled in (each row contains 6 textfields for 6 
> years worth of data).  And on top of that there is an option for the 
> user to add non-standard rows based on a DDLB (so, dynamically add rows 
> to the page - and again 6 text fields per row added).
> 
> If the above wasn't enough, on page 4 the user can select to add another 
> series of data for pages 3 and 4 and will go back to a blank page 3 and 
> can repeats pages 3 and 4 as many times as needed to enter all the data.
> 
> The structure of this beast is unbelievable.
> 
> I currently am using 4 arrays (one per page). the page 1 and 2 arrays 
> are 1d..not bad...
> The page 3 and 4 arrays can get up to 4 dimensions as it is now.  
> 
> To give you an idea on page 3:
> 
> //non-dynamic row
> $wizpage3[operation][rowname][year]=data
> 
> //dynamic row
> $wizpage3[operation][dynamic_rowname][row_num][year]=data
> 
> And when you stuff, all those into the session array the dynamic rows 
> makes it 5 dimensions...sheesh...
> 
> I DO have the data storing in the arrays just fine for as many times as 
> the user needs to enter pages 3 and 4.  Originally I was planning on 
> storing the arrays in the page itself as hidden fields, but it quickly 
> became obvious that the page would be huge with all the hidden fields if 
> a user entered pages 3 and 4 a bunch of times).  So I am using a session 
> variable to store the arrays.  The problem with sessions is if the user 
> hits the next/prev buttons in their browser(not the ones I coded into 
> the page)... you get page expired errors, which I really don't like...
> 
> All of the data entry is actually the same dsp_ page with if statements 
> to control which page is displayed.  I have in-form nav buttons 
> (next/prev) to move back and forward in the wizard interface.  
> 
> I guess I am more curious as to how other people would handle something 
> this complex.  I have been wracking my brain as to whether or not I have 
> gone down the wrong path with this, or could have made it simpler, but 
> it works...  The more I code, the more I worry about how unwieldy this 
> could become...
> 
> Maybe I am venting more than anything... heh... its friday...weee :)
> 
> 
> 
> Cheers,
> Keith.
> 
> 
> 

==^================================================================
This email was sent to: [email protected]

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9
Or send an email to: [EMAIL PROTECTED]

T O P I C A -- Register now to manage your mail!
http://www.topica.com/partner/tag02/register
==^================================================================

Reply via email to