Category - Projects
Database Structure for Dynamic Forms
One of the core ideas and focus for this app was to have truly dynamic forms. Imagine an interface where you can drop and drop some input boxes, or create a dropdownlist to create a complex form. Then you could go to a template in your browser and see the insert form already built with validators. Or have a list of all the entered data.
This means our database would have tables like:
- Forms (stores the basic information of the forms)
- Form Rows (stores the basic information on a row and what fields are in that row, this way we can have more then one input on the same row)
- Form Fields (the basic info on the individual input fields, which either accept an entry, or are a list of selections like a dropdownlist)
- Form Field Selections (to store the options available for the fields that have selections)
- Form Field Types (to keep things sweet, we have field types like radiobutton list, dropdown list, textbox, etc.)
- Validation Types (like a required field, compare etc)
- Validation Options (some validations have special fields that should be filled, like a compare validator has to know what you are comparing against, and a regex has to have the expression it's checking against)
- Form Field to Validations (we need to know what validations need to be applied to what field. We may have a textbox that has a required field, but another that doesn't)
- Form Field To Validation Options (to store the data on the options filled out for any of those applicable validators)
Now all of that will just let us store and hold the data of the form itself.... but that has nothing to do with the data that the end user is actually pushing in!
So as we explore content we now have a whole host of complexities that come into play like:
- Content (this will store the basic universal data for any content)
- Content Groups (needed the ability to group content together by more then just the form, because you might want to use the same form for multiple "groups", for example, the slider on the front page, is a content group)
- Content Data Entries (this will store the field id and the value of the data. I placed a small nvarchar 250 field in here and then a nvarchar(max) for storing large multiline content like from an html editor. The field type table tracks which field it's supposed to push data too)
- Content Data Selections (for multiple selections, you need to store what they selected here. This allows you to change the name of a form field selection and it will cascade across everyone that had selected that option)
There were a lot more intricacies I came across as I worked on building this, for example Validations can have a Validation Mode that defines Edit, Insert, Both. So, if you have a validator that you only want to show on the insert mode of the form, but not the edit, you can.
This is over a dozen database tables. But the result is a full code generated form and content based only on the data in the database with only one exception, which we will talk about in the next post ;)