What is the design behind custom dynamically generated forms?
Would like to implement something like drupal's CCK.
In the control panel, the owner of the form designs what fields should be in the form and in what order the form fields should be in, as well as the field's attributes such as "required: yes/no"
Once the form has been designed the end user fills it and submits.
Currently I'm able to get the user to create the custom form, the problem is with the storage and retrieval of the content of the form.
Usually, when one writes a form, who's data is stored in the db, the code that will be needed to enter the form's data into the database is also written. How is this code to be written when the form is always changing with different fields almost every time?
Basically, what I need is to understand the database design that will allow the storage and retrieval of custom forms, despite the number or type of fields.
I do not want to have a new table for each form submission, nor do I want to manually write code for each form.
These are the main field types that I will need
- Text Box
- Select List
- Radio Buttons
- Checklist
- Date Field
- Text Area
Below is the database design that I came up with
table1
id, formid, type, position, name, value, select(foreign), multiple
id: Unique id for that record, auto
formid: the unique form id, all fields in a particular form will share the same formid
type: it could be textbox, select list, radio ....
position: is the fields the 1st, 2nd, or 5th?
name: the unique name for the field
value: if it is a textbox, the default value is entered here. If the type of field does not need a value, then it stays as a null.
select (foreign): if it is a select list box, then the foreign idnumber will be present.
multiple: if you want to allow multiple selection in that listbox, then the value will be 1 or else it will be null
table2 id, select, value
So, if you want a select list box field, in table1, you will have the type as selectbox, and you will have the value of the foreign key related to "select" in table2.
If you want a text area, type in table1 will be text area, and if need a default value, you enter it, or else it will be null
table1 does not have the list of all attributes, but you get the point. Depending on what field type you want, determines which attribute you will need to fill. If that attribute will need to store extra data, e.g. a select list box, simple do a relation, as it has been done with table2
To render the form, the system interprets the data in the database and create fields accordingly.
So far so good, but, how do you store the data in the database when the fields are always changing?
What sort of db design is needed to store such data?
Is the above the right way of generating forms dynamically?
If you got ANYTHING, please share :-) Thanks