Question

So, I’m building a form that my users can customize based on their needs, and then accept responses to it from THEIR clients. Think of it like a Google Docs Form (I can log in and make a form of any size, with lots of dynamic fields).

What is the typical way to create this – and are there PHP libraries that are good at doing this already? As of now, it’s my plan to just think of every field they could ever want, and associate a boolean logic with that field for that user. In other words, let’s say these are all of the possible fields that could be used:

• Name
• Phone
• Email
• City
• State

Each of those can be turned “on” or “off” for any of my users, so that it is (or isn’t) displayed and used for THEIR clients. This seems like a very work-intensive way to do things, and I’m wondering if it makes more sense to allow a completely dynamic form to be created by them. But then again, that sounds like a lot more work to me…

So the question – Is my logic sound, and a standard way that people would code this? Why/Why not? Are there any libraries available that I can customize into my WebApp to allow completely dynamic form creation?

Thanks all!

Answer 1

We’ve built this before as an internal project for our own purposes. Good thing too cause it was much more complex than we wanted. We went with a custom solution because at the time we did not see any options to do basically what you wanted: local storage and highly customizable. We may have found something close – I don’t remember exactly – but the part of your question I will address is whether or not your logic is sound and not necessarily if there is an existing library.

I would strongly suggest you do NOT think of every field they could want. You will lock yourself into a structured package that would be horrible to maintain. Abstracting this is the only way to go.

We made it so each form is an entry in the forms table. Simple enough. Form name, client id, status (active / disabled), etc.

Each field is in a relational table keyed to the form id, of course. This entry stores the label, id, type (select, multi select, radio, text, textarea), required (bool), order, active or disabled, options (like tinymce enabled, etc), etc.

Then each field has a many to one relational table for the options, if applicable. For dropdowns, radio buttons, etc.

This is not terribly complex initially, but when you start improving things – or even wanting to separate things into pages – it becomes worse and worse.

Point is – abstract it. You will be much happier in the end.