Form framework

As a
requirements engineer I’m often confronted with the abilities of a form
framework (or web framework) being used by the developers on the team or rather the disabilities. This keeps frustrating me. Hearing that a certain feature
takes a lot of time because the framework doesn’t support it out of the box. In
this post I will list some features which I think every form framework should
support.

Two step view

Basically
this is more like the solution to a problem (see
http://martinfowler.com/eaaCatalog/twoStepView.html). A lot of form frameworks
seem to produce HTML which is rather solid. Changing the display of labels from
the left side of an input field and placing it above the field is in a lot of frameworks a
real problem. This would mean change to all code which produce a form. This
should be like creating a new template for all form elements. How well can your
form framework cope with this change? How well does it support this sort of
change out of the box? Can you define where labels are being displayed? For the
whole form and per field?

One-to-many forms and subforms

Another
type of requirement I would put on a form framework is support for one-to-many
forms. What I mean by this is the ability to have a single masterform which
will for example provide the input fields for the orderdata and a form below which can be
multiplied within the same screen for providing orderlines. Does your form
framework still pass this requirement?

Filters

Database
values are not always in the same format as the input values or display values.
Does your form framework make it easy to implement filters or transformators
for data which can be edited through the form? Can it for example handle
postalcodes with and without spaces but when asking the value for the form from
your code give back the value without the space?

UI Widgets

We all know
a HTML form can have several input types. This is being defined in the
specifications of HTML. But can your form framework go beyond this? A list of
UI widgets which I think a form framework should be able to have and can handle
correctly in validation: Richtext, Time, Text, Multiline text, Select list, Checklist,
Radio button groups, Password, Numeric, Float, File, Multiple files, DateTime,
Date, Checkbox, Time period, Date period, Currency, Slider (for setting ranges
or a single value in a range) and Floats.

So does
your form framework have all these UI widgets and does the validation happen at
the clientside? Does it support text input by providing a list of special
characters when asked for it? Can it provide support on textfields like the
“To” field of Microsoft Outlook does?

Validation

A lot of
frameworks support validating fields. But does it also provide support for
“depends on” fields.

Defining a
relationship that a certain field will enable the other field (a checkbox for
example)? Can it mark a field as invalid and put a red border around it and
show a message alongside or just below the field? Can it mark the form as invalid
and provide a list of errors on top with links in it which point to

the field?
Does it show required fields, but does it also explains what the “*” sign
means?

Odd value detection
A lot of frameworks can mark a
field as valid and invalid, buts sometimes we can specificy what a odd values a
field can contain (an orderdate having a year 2001 when it’s 2010). This would
introduce a manual validation step, where the user get’s to see the form again
with odd values marked. The user would then need to verify his data and confirm
it by submitting the form again.

Confirm
screen
The previous paragraph indicated another pattern which a decent form framework
should support, presenting the user with a confirm screen, confirming his
entered values. You never know how important it is to get the input right the
first time.

Popup screen
Does the form framework support popup screens for searching an entity which has to be selected in the form?

So do you miss any
support from your form framework?