My company have a site that has some important forms. Now, we want that the we may have a tool where we can create / edit our forms.
Each form is tied to a database table, and know that it is some thing that needs a lot of effort.
We plan to have about 30 new forms, and this causes us to think for a form creation thing.
I plan to have an area in our system where the administrator can login, and create the form and give it a name. Then, the admin will click on Add fields,
then he can enter the field name, and select the type. (Dropdown, Text, Check box, and radio box) if it is text field, then it is simple, but if it is a Check box, radio box and/or the dropdown, then it will ask for the options and their text.
So I have to setup a few more tables:
1) Form master
2) Form Fields
3) Form Fields options in case of Check Box, Radio Box, and dropdown.
Now, when some one fill in the data in that form, i m stuck here, how and where the data will be kept ? can any one please guide me on this ? or can give me a better idea ?
This, currently, sounds more like a database issue; I'll move the thread there for now.
Unless the domain is modeled in the exact way as the database, this is probably a bad idea. I mean the abstraction that occurs between the domain and databases happens for good reason. Removing that abstraction is going to make things a nightmare for none-technical users. The more they will have to understand in regards to how things work from a programmatic stand-point. People are really stupid so the more things can be abstracted and be presented in a more understandable format that reflects the business model at hand the better. In most cases business work flow never directly correlates to the database structure without different levels of abstraction and organization that is just about impossible to automate unless many sacrifices are made. Even at that point there is always edge cases that are difficult to for see in the beginning. Now, I'm not saying it can't be done what I'm saying is in all cases it results in a sacrifice in terms of usability for the average user. Than again I guess I would need to know about the a specifics of these 30 forms to say for certain. What you are essentially talking about is scaffolding though. Most frameworks have a feature to read the model and create a form. The form is just a list of everything in most cases, no organization, tabs, logical grouping, etc but a form none the less. Having said that would this be a single form per table? If it is one form to a table its probably easiest to skip having form tables and derive the form based on the tables schema with widgets that are based on data type of whether the column is a foreign key perhaps. Though again as a programmer you always have to remember the majority of users are idiots. Usability decreases as abstraction decreases unless you start to make sacrifices in terms of the database structure itself.
ironically, you lost me after "people are really stupid."
interesting subject though and one in which I too have an interest. Are you suggesting that compiling the structure of a form is overly difficult for a non-tech person? if so, I tend to agree and I am seeking a way of keeping it simple yet flexible.
(hopefully not construed as a hi-jack).
I do not want to create the database tables when the form is created. I only want to keep the form's, form's fields and options of form's fields in the tables so that on the frontend, I can pick the form id, and get all the fields/lebels associated with that forms and in case the field is check box/ radio button and dropdown, then also collect the options for those fields.
So I plan to have my schema like this :
1) Form Main (here I will keep the main data about the form, like name, id and description of the form) for example, A BUSINESS PROPOSAL FORM
2) Form Fields (here I will keep data about all the fields in the form) for example,
First Name, text field,
Last Name, text field,
Grad Year, dropdown
Practicing Area, check box
3) Options of Form Fields (here, I will keep the options for the form's fields if they are Drop down, Check box and radio button.) For example,
the ID of the form field from the 2nd table above, and then value/text. suppose that the ID of Features field above is 52 so it will have :
52, Medical Science
52, Medicine Science
52, Bio Tech
52, etc etc etc
Now, when my script get a form ID, it will grab the form details from the Table no. 1, and collect the fields and their options from Table No. 2 and 3. and now the form is ready to fill and submit.
Now, the issue:
To collect the data user enters on this form, what is the best approach ? I do not want to have 1 table for each form type. It will be 1 table for all the forms I have.
Can I have a table like this:
ID, Date submitted, Form Id, Field Id, User Entered data
1, 2011-02-01, 13, 1, Zeeshan
2, 2011-02-01, 13, 2, Hashmi
3, 2011-02-01, 13, 3, 2009
4, 2011-02-01, 13, 4, Medical Science
5, 2011-02-01, 13, 4, Microbiology
Suppose that user enters names and grad year and then select the 2 check boxes for Medical Science and Microbiology ?
Can I achieve the same by saving my data as a XML ?
yes, but you are giving up all hope of data integrity if you do
Is there any way to achieve this that you people may suggest ?
So many people around but not a proper suggestion ! - Heartbreaking !
Thank you everyone.