Let's take a look at the task of processing user forms and try to find the most common steps. They will describe generic functionality of a form. First of all, a form must be presented to user. This includes rendering graphical representation of form objects (which is carried out by browsers quite efficiently). Then we must display the initial values; this should be governed by application logic. Then the user's input must be received and analyzed. We receive a set of values from user. At the abstract level the decision that is made on this stage would usually be: can this form be considered completed or should we go back and ask user to correct something.

Let's first look at the situation when we need something corrected. In this case an application must display the form again and give some explanations about what went wrong (display some error messages). Besides, a well-mannered form should preserve values entered by user, at least the correct ones. Now suppose, we decide that the values are good enough to allow us to continue. Then these values (or some of them) usually get stored somehow (in a database, in session variables). Finally, another decision is made: where do we go from here? It is often based on values entered and, of course, follows some paths defined by programmer.

Now, what should we try to achieve by the object analysis? The best would be to program generic behavior in parent class(es) once and forever. Then from that moment on we will be able to only concentrate on context-specific steps for each new form that we develop: check values, store values, decide where to go from the form.

The key element will be a generic form class that I called FormProcessor. Let's first have a general idea about how it works. I like putting forms into separate files. There's nothing that makes it necessary, it just makes things easier, for example, to edit them in visual editors. Also, I usually have forms that 'submit to themselves', in other words I usually group a form with code that takes its input. One idea is to create instances of FormProcessor's sub-classes in the beginning of such files. Then, this instance will 'tune in' the environment and will be able to have complete control over displaying the form and working with it further on. By 'tuning in', I mean deciding whether this particular form was displayed and submitted before and we should now check the input. If it has never been submitted before, it should be displayed for the first time. Object-oriented technology will work for us in both situations. Generic framework within FormProcessor will run one of the virtual member functions -- either for checking or for displaying the form. Notice: all we will have to do in each particular form's class is override these virtual functions. In the same way, we will override the function responsible for storing form's values. Again, generic class will decide when to call it.