Analysis
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.
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.
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.
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.
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.
