Automatic form generation
Current status
The current situation is as follows:
- the forms are generated automatically from the record definitions:
- the whole form is a big table
- there are two types of the cells in the table: description and field. Each row holds only two cells.
each of the cell has its own class: the class name depends on the cell type. If the cell is a description cell, its class is long_field_name_description, otherwise it is long_field_name.
if the error occurs, the cell changes its class to form_error
- solution is not flexible, could not be formatted without an effort and rather heavy
- it is not possible to
- group the fields into fieldsets
- attach the comments to the fields (specifying format or explaining the restrictions - max length and so on)
- place the error comment next to the field
Proposal
There should be at least four types of the form generators available:
div generator which surrounds each record field with div tag
table generator which packs the form into table, but uses th for headers, id 's instead of class
paragraph generator that builds the form as a set of paragraphs p
list generator which creates the form as an ordered (or unordered) list li
Each field of the records should be rendered with consideration of
the name/description of the field: that should be short string describing the field, like login, e-mail
- error part - where the error description in case of validation failure appears - with e.g. image, changed background color or something that is intuitive and attract user's attention. The error description should be human-readable. It is displayed only if necessary.
- input part - the actual input field - the HTML input tag
- comment part - helper text, describing the limitations or explaining the format
Moreover, each field could be declared as required or optional and that could be parametrized with another option/class.
The whole form is split into fieldsets:
- each fieldset has its own class:
- we can collapse (js hide with show button) some less important fields (that have the default values, like "visible from" in the blog post that is initialized with the current date)
- we can use the different CSS styling for different groups
- fieldsets can have names - that describes the fieldset category
The changes trigger the whole wpart application rewrite (but it needs it anyway). Since the majority of the wpart_ implements the same functionality, there could be some wpart_generic module that will deal with all common situations.
Moreover, some simple JavaScript validators could be implemented on the client side.