How to create flexible web forms in ASP.NET

Question

I use asp.net and I need to create an application in which we can easily create forms without re-creating the database and, preferably, without changing the create / read / update / delete requests. The goal is to allow customers to create their own forms with drop-down lists, text fields, check boxes, even with a one-to-one relationship to another simple form (stretching it). The user should not be able to create the forms themselves, but I do not want to add tables, fields, queries, a web page, etc. Each time a new form is requested or changed.

2 questions: 1) How to create a flexible database for this (in SQL Server)? I can imagine two ways: a) create a table for each data type (int, varchar (x), smalldatetime, bit, etc.). It would be very difficult to create adequate queries. b) Create a form table with many additional fields and various data types if the user needs 5 integers or 5 date fields. This seems like the easiest, but probably rather inefficient use of space.

2) How do I create forms? I was thinking of creating an xml sheet in which validations, data type, control for display, etc. were indicated as a list. Then I will parse the XML code to create the form on the fly. Probably using css to create the layout (this should be manual, which is good).

Is there a better / better way? Is there something I could look to get ideas? Any help is greatly appreciated.

Answer 1

This sounds like a potential candidate for InfoPath. Blush first, he will do most / everything that you ask.

This article provides a brief overview of creating an InfoPath form based on an SQL data source.

http://office.microsoft.com/en-us/infopath-help/design-a-form-template-based-on-a-microsoft-sql-server-database-HP010086639.aspx

I created a fully customizable solution, as you describe, and if I ever did it again, I would choose either 1) a third-party product, or 2) less functionality. You can spend 90% of your time on a 10% feature set.

EDIT: re-read your questions and here is some additional feedback.

1 - Flexible data structure:. A few things to keep in mind are performance and the ability to write reports against data. The more general the data structure, the more difficult it will be to achieve (again, based on experience).

Unlike performance and report availability, Microsoft SharePoint uses XML fragments / documents in shared tables for maximum flexibility. I can not argue with the features of SharePoint, so it does the job and greatly simplifies the data structure. XML will work well when done correctly, but it will be more difficult for most people to write queries against XML. Although XML is a “first-class citizen” for SQL Server, it may or may not work just like an optimized table structure.

2 - Forms: I implemented custom forms using XML transformed by XSLT. XML is often a good choice for storing form structures; XSLT is a monster for itself, but very powerful. For what it's worth, InfoPath retains its form structure as XML.

I also implemented dynamic forms using custom controls in .Net. This is a very object-oriented approach, but (depending on the complexity of the user interface) a significant amount of code may be required.

Finally (again, using SharePoint as an example), Microsoft implemented horribly complex XML list / form definitions in SharePoint 2007. Complexity loses to many advantages. In other words, if you are following the XML route, make your structures clean and simple, or you will have a maintenance nightmare at your fingertips.

EDIT # 2: Regarding Scott's next question, here is a high-level data structure that avoids data duplication and does not rely on XML for most of the form definition.

Caution: I just put this project into SQL Management Studio ... I spent only 10 minutes on it; the development of a flexible system of forms is not a trivial task, therefore this is an oversimplification. It does not take into account the storage of user input, just a form definition.

Tables:

Form is a top-level form table that contains (as you might have guessed) a collection of fields that make up the form.

Field - general fields that can be reused in different forms. For example, you do not need 50 different Last Name fields for 50 different forms. Pay attention to the column "DataTypeId". You can store any type that you need in this column, for example, "number", "free text", even a value indicating what the user should select from the list.

FormField - allows a form to contain 0-many fields in its definition. You can even expand this table by indicating that the user can add as many fields as they need.

Constraint is basically a lookup table that defines the type of constraint (possibly the maximum length, maximum occurrences required, etc.)

FormFieldConstraint - Binds a constraint to a specific instance of a form field. This table combines a specific form with a specific field with a specific restriction. Note the metadata column; this could potentially make good use of XML to store constraint specifications.

In essence, I propose creating a normalized database with or without zero null values ​​and without duplicate data. The structure, as I described, will lead you to the path to this goal.

Answer 2

I think that if you need truly dynamic forms stored in a database, you will have to create some kind of dictionary data table.

For example...

UserForms --------- FormID FieldName FieldValue 

FormID refers to the parent form (so you can aggregate all the fields for one form. The field name is the name of the entered text field. FieldValue is the value entered / selected for this field.

Obviously, this is not an ideal solution. You may have problems with dynamic data entry, but I will leave the implementation of this to you.

In any case, I hope this gives you the opportunity to start thinking about how you want to achieve something. Good luck

PS I found using webforms with .NET for complete pain in creating a dynamic form. In cases where I had to do this, I almost completely dropped it and used my own HTML elements. Then they redid my form using the necessary values ​​from Request . This may not be the perfect solution either, but for me it worked best.

Answer 3

We created a form system similar to the one you are describing with a circuit very similar to the one at the end of Tim's post. It was quite complicated, and we really had to struggle with standard WebForms controls, such as DetailsView and GridView, so that they could perform CRUD operations on response groups. They are used to bind directly to the properties of the object, and we force them to first search for the field identifier in the dictionary. They don’t like it. You may want to use MVC.

One tricky question is how to save answers. We ended up using a table with the Key FieldId, InstanceId (for example, if 10 people fill out your form, 10 copies) and RowNumber (because we support multi-line forms for things like employment history). Instead, I would recommend making your AnswerRow a first-class concept with its own instance-bound table, and that the answers are related to AnswerRow and Field.

To support different types of values, we needed to create several response fields in our answer table (AnswerChar, AnswerDate, AnswerInt, AnswerDecimal). Each of these cards refers to one or more types of fields (date, time, number, etc.). Each type of field has its own logic for representing the value in the user interface and puts the value in the corresponding property in our response objects.

All in all, it was a lot of work. It’s worth it because it’s the essence of the product, but you’ll definitely want to save the cost before embarking on such a project.