Im partway through building a very complex GF form for an insurance company. I want the user to be able to fill in generic details to get a quote, and then continue to fill out lots of details for a final quote; and then go on to buy the insurance and the relevant pdf documents generated.
So far its turning out to be a very complex form becuase there needs to be a lot of conditional logic involved. Its imperative that the right questions are displayed depending on what has been previously filled in. The form is also doing the relevant calculations as the user is filling in the form.
Im using the multi-page form interface.
So far I have 200 fields in my form and by the time the form is finished its going to be nearly twice that. I cant help but think this is getting a bit bloated and an inefficient way to deal with such a complex form. It also needs to be easily maintained by the client, so having hundreds of fields to scroll through in the backend to get to the field you want to edit isnt ideal.
Is there a more efficient way of doing this? For example, splitting the form up into smaller forms? I know you can GET variables from one form to another, but with so much data POSTING variables would be more apt.
Im interested to hear any thoughts or advice on managing such a complex form.
Hard to say without viewing the form, but there usually is. In my early days of using Gravity Forms I’d populate hidden fields to do some of the same affect as Pre-Rendering (or other Hooks), JavaScript, and AJAX. If you already are using some of those than you are probably doing just fine.
Thanks Parkbum. Im using hidden number fields to do the calculations on the fly. Ive had to do some custom php which is executed when the Next button is clicked. This is mostly custom validation stuff. (comparing 2 numbers against each other etc).
Im concerned about code bloat becuase - obviously - even though a lot of the fields are hidden or only displayed under certain conditions - all the field code is still outputted in the html. Fine for 30+ fields, but a few hundred fields!?
I wander if anyone on here has dealt with any crazily complex GF forms with loads of fields(?)
Coding for your calculations will definately be better than redundant fields unless they are fields that change regularly. Even then, there are better ways to save/change that data, and then fetch it. Hell, even if you don’t want to code a new plugin, have one form for the data with a sole entry, then get_entry the fields you need when you need them.
As for people with experience with large forms, I’m fairly handly. I have one that is a Travel Agency Itinary system. It’s what I learned JavaScript and AJAX on. Most impressively, it chain selects a list of client companies, and conditionally spits out their requested data, while updating fees and percentages. It then charges the caller if needed, spits out a PDF of their Itinary, emails multiple people, changes the client’s user_meta and posts an entry to another form. Let me know if you need to subcontract.
One final note: I’m currently researching adapting sessions cookies for non logged-in users, which is not described yet in the git repo’s readme doc - I’m not sure of my time scheduling for this enhancement. Is this a requirement for your use-case ?
Im almost finished 9 months of 34 Insurance forms with average 300 fields per form.
Its for commercial business. Was wondering if you found a solution.
As most of the forms request the same details, except for the cover, or certain risks, I was dabbling with ONE FORM, then adding the cover and risk, dependiing on the inital selection from the customer