Hola,
Sam Newman wrote:
> I'm in the process of writing a web application to validate new users
> signing up to a service we provide. What I want to do is to take user
input
> via a standard HTML form, validate the information on the client side, and
> if there are any errors redisplay the original page and inform the user of
> the problems.
> [...]
I'll share with you what I did, which is somewhat similar but less
sophisticated than the solution in the JavaWorld article--perhaps
we can solve this problem as a group and come up with a good solution.
I have modified a version of the tablegen JavaBean-from-JDBC-datasource
JavaBean generator program to produce a JavaBean class for a table in
a database, a "form helper class" which does form validation, processing,
etc., and a form servlet class that sets up the form helper class and
forwards to a JSP form presentation page (or any of several error pages
based on form validation and processing results).
Error strings, form validation rules, etc. are located in the form helper
class which is put into the request (somewhere, anyway) and used by the
form presentation page to fill in the form with current or recent values,
display error messages if appropriate, etc. (I also create a form display
JSP fragment file that uses our custom tags to partially create the form
along with error messages etc.)
Now, there are several things wrong with my existing solution because I just
don't have the time to implement them and I am a newcomer to much of this
technology:
- The form validation processes are not implemented. I currently only
validate
for existence of a form element (empty string check) for every element.
- I don't have things for different form element types (but plan to); I only
deal well with strings. For instance, right now I just hand-code a
password
confirmation value check.
- Error messages are hard-coded in the form validation routines.
- Ideally, the form definition should be an XML document with the form
display
being a [perhaps templated] page with a transform from the XML to the doc.
- In addition, data types, validation checks, etc. should be defined in that
XML document and used to perform validation and error message loading.
- Error messages should be a collection of strings to allow various
retrieval
means by the error display page (normally the original form), for
instance,
an error (or error list) for a particular form field in that form field,
and
a complete error listing above the form.
- In a perfect world ("assume a spherical horse...") form to bean mapping
would
also be in that XML file (allowing easier deployment of multi-table forms,
which is one reason I started thinking about this, but I've only had a
week,
and don't have time to deal with it properly right now), but I don't know
how critical that is.
- Loading JavaBean values in JSP is nicer than in a servlet--which makes
form
processing initialization in a servlet not as enjoyable. YMMV.
- I'm the only one at the company that can deal with any business logic now;
even JSP scriptlets are tough for these guys.
What _is_ nice about my existing solution is:
- Errors on pages using this method are in a consistent location (near the
form
element) in a consistent style (code cut/pasted from JSP fragment file).
- The JSP page consists of our normal template file, an import and retrieval
of a form helper class instance (instantiated by the form servlet), and
the
form (our custom tags, input field, and error msg with an if/then block
around
it so it only displays if that field reports an error). Pretty clean.
- Complex validation logic can be carried out relatively easily in the
servlet,
for instance, in our current system, when a new user is created several
other
database tables must be created and validated.
So, any more thoughts/comments?
--
Dave Newton, [EMAIL PROTECTED]
