Tim Heald
ACP/CCFD :)
Application
Development
www.schoollink.net
-----Original Message-----
From: Steve Ball [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 17, 2002 1:59 PM
To: '[EMAIL PROTECTED]'
Subject: RE: Complex forms: the horror! :)what does cf_embdFormFields do?
-----Original Message-----
From: Timothy Heald [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 17, 2002 10:24 AM
To: [EMAIL PROTECTED]
Subject: RE: Complex forms: the horror! :)
With that much data I think I would store it in the db each request, that
way I wouldn't have to manage all that data from every page. Now this would
however create a problem if they wanted to edit the data that they already
entered. I have never had a set of form data so large that I couldn't just
use cf_embdFormFields before, so I am not sure what the most efficient way
of doing this would be. Do you know what the most likely connection speeds
will be for the user? If they are all on LAN/Broadband speed connections I
don't think having the data in form fields could get to be to big of a hit
(unless of course those textfields contain lots of data.Tim Heald
ACP/CCFD :)
Application Development
www.schoollink.net> -----Original Message-----
> From: Keith Young [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 17, 2002 1:02 PM
> To: [EMAIL PROTECTED]
> Subject: Complex forms: the horror! :)
>
>
> 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 message is intended for the sole use of the individual and entity to whom it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended addressee, nor authorized to receive for the intended addressee, you are hereby notified that you may not use, copy, disclose or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete the message. Thank you very much. ****************************************************************************
==^================================================================ 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 ==^================================================================
