At 07:43 PM 8/30/2002 -0600, you wrote:
Is there any documentation available that shows how to implement a custom
validator for a field form with the validator? I've read the section in
the O'Reilly book, but I found it to be more confusing than helpful.
Thanks,
david
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Don't know exactly what you have in mind, David, but there is this general
statement which I have found useful and is probably completely off the
point you are trying to get to. Won't hurt to try, I suppose.
Extending the scope of the struts validation
From: Frangois Rey
Subject: Extending the scope of the struts validation
Date: Sat, 23 Jun 2001 07:32:15 -0700
You may remember some of my earlier postings about a mapper framework that
we use as a
validation framework. I now have the support in my company to make it open
source.
However, I first would prefer to:
1- Invite the community to realize that a validation framework, definitely
required in
Struts, is only part of a larger requirement.
2- Propose the extension of the scope of the TO DO item for validation so
that is does
a bit more than just validation but also convert the value and transfer
them to where
they should end up.
I know I've already approached this topic in my previous postings, but I
there hasn't
been much follow up on this. However I still believe those that have
developed web
applications with Struts have been confronted to the same problems we have
been trying
to solve. So instead of submitting a big zip file that may or may not get
interest, I
first would like to share the reasons that led us to developing the mapper
framework.
In our company, after evaluating a few options, we have chosen Struts as
the base
framework for developing web applications. We have developed our own simple
extensions
to Struts in order to provide added support for things like i18n and
transaction
integrity. Form validation was also a top item in our list of needed
extensions, but
looking at the Struts 1.1 TO DO list we decided to wait and see what the
community
would come up with. For one of our customer project, we have looked at the
validation
framework from David Winterfeldt in order to implement form validation. We
were very
attracted to that framework because it offered configuration-based
validation and also
client-side validation. However beyond the simple need to validate form
properties, we
also needed to do type conversion (text-object) on each field and populate
another
bean (a command bean) with the converted values. Having a framework that only
addressed the validation part meant that we would still need to do a lot of
custom
coding in order to convert values and populate our command beans. And in
addition to
this, we also needed to do type conversion and populate presentation beans
when
receiving result messages from the backend, which means even more custom
coding.
I think by now you should understand and hopefully agree with me that
validation is
actually only the first part of larger need: once values have been
validated, you need
to do something with them. Whatever is needed to do, it should not be the
responsibility of the ActionForm. The latter should remain a View object
that is only
a placeholder for user input. Business logic should be separated into
another set of
objects. Actions seem to be a good place for implementing this business
logic. However
doing so ties the logic to the web application framework in a way that
makes the reuse
of this logic outside of a web application difficult. So a good application
architect
would usually factor this business logic into another set of objects that
is not
dependent from the web application. Often these objects are actually just
sending
requests to a backend where the real business logic resides. But whatever
these
objects are (the real Model, a PreparedStatement, or a proxy to a Model layer
implemented on another server), the point is that these are objects which
need to be
initialized and populated with the user input.
Coming back to our project: we have an EJB backend accessed with a messaging
framework: you send command messages (objects), and you get result messages
(objects).
And of course we wanted to avoid lots of custom code in our actions because
it's
tedious, not so fun to write, and increases the maintenance burden (more
lines of
code). So we took the decision to develop the mapper framework. What we now
have is
used almost all over the place in the application we're developing, for the
things I
mentioned above: validation, type conversion, and bean population, and for
both
directions: forms - command messages and result messages - presentation
beans. The
code in our Actions.perform() has decreased dramatically to just a few
things. When we
get to the Action, the ActionForm.validate() has successfully validated the
user input
with its
