Documentation for writing custom validators available?

[David Geary <sa...@earthlink.net>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Documentation for writing custom validators available?

[Eddie Bush <ek...@swbell.net>]

David Winterfeldt has a site ... but I can't think of it right off.  I'm 
"reasonably certain" part of the URL has part of his last name in it, 
but I don't remember how much -- and searching the archive for his last 
name would probably give an exhaustive list.  *goes to check folder* ... 
you're in luck!

http://home.earthlink.net/~dwinterfeldt/

Try that out.  I don't know if you'll find it any more/less helpful than 
Chuck's book, but it's another resource :-)

Regards,

Eddie

David Geary 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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Documentation for writing custom validators available?

[micael <ca...@harbornet.com>]

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:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>


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 mapper. In the Action.perform(), all we do is to ask the same 
mapper to
create the command message and populate it with the converted values, send 
this object
to the backend, ask another mapper to process the result message, and then 
forward to
the JSP.

Now that I have explained why validation is just part of a larger story, 
one might say
that a validation-only framework is a good start anyway. The problem with that
approach is that actually validation and conversion can be one and the same 
thing: if
you are able to convert a value into something else, this is at least partly
validating the value. Using the SimpleDateFormat class to create a Date 
object from a
String value will fail if the string is not in the proper format and does 
not contain
proper data values. So the point is that we should not dissociate 
validation from type
conversion. In some cases the validation is completely fulfilled by a 
successful
conversion, in other cases there is no need to convert but only to 
validate, and in
some other there is no need to validate or convert.
By looking at recent posting I think already most of us agree with the fact 
that the
validation framework should also be able to convert values. I don't think I 
really
need to convince people on this. The real extension that I want to propose 
to the
current scope for validation is the ability to transfer the converted 
values to their
real destination: most likely in a property of another object. Think about 
it: how
much more is it? If the validation and conversion are automated, no custom 
coding is
required for this anymore. But then in the current scope you still need to 
extract
those validated/converted values and, as I explained before, use them to 
populate
other objects. Automating the population of other objects with converted 
values is not
such a big effort when using PropertyUtils, we just have to specify the 
destination
object and the recieving property names at the same place where we specify the
validation/conversion. If some of you still think that just a 
validation/conversion
framework is again enough as a starting point, then think about it again: 
how much
more is it have the transfer functionality compared to the lines of custom 
code you'll
have to write to populate other objects with the converted values?

Having a validate/convert/transfer framework is really what we have tried 
to achieve
with the mapper framework. Because it does the job quite well and has 
increased our
productivity, I felt more compelled to write our story rather than just 
sending a big
zip file with the source. Whatever the Struts validation become, I think a 
framework
similar in scope to ours would really benefit to those developing 
applications with
Struts, and would make the Struts offering even more attractive.

If with this posing I also created an interest in making our mapper 
framework open
source, then great. I started to develop it 6 weeks ago and there are 
plenty of room
for improvements. For example it does not generate client-side javascript, 
it is still
creating lots of object at run time (no object recycling), and it only 
works from one
single configuration file (a bottleneck when using a repository within a 
large team).
So making it open source could be a great way to improve it and could give 
a kick
start for the Struts validation framework.

If you want to know more about the mapper, I invite you to read some of my 
earlier
postings, in which I also sent a sample configuration file. The mapper 
framework has
been developed independently from the Struts MVC classes. It is only 
dependent on
these utility packages:
- Struts PropertyUtils
- Struts Digester (and therefore an XML parser - Xerces of course :)
- The Regexp package from Jakarta (used in one validator )
- JavaCC/JJTree for parsing custom validation rules

Some of the logic for digesting the XML config file required some 
extensions to the
PropertyUtils and Digester. The PropertyUtils extension is for supporting 
what we have
called 'string keyed' properties, which are properties with accessors of 
the form
getProperty(String key) and setProperty(String key, Object value). The 
extensions to
the digester were for supporting the resolution of system entities (only 
public
entities can be resolved at present), and for adding convenience methods in 
order to
add our own rules to digester. The new rules we use are called SetTopNow, 
SetNextNow,
SetPropertyFromAttribute, SetInitFromObjects, CallMethodNow, etc (hopefully 
these name
gives you a rough indication of what they do).

If the interest is there, I can submit the code (although I'd prefer 
waiting another
week to finish some doc). But I don't think it should be within the Struts 
project. I
also don't think the strutsx would be an ideal place either because as I 
said it does
not depend on Struts, only a bit now because the PropertyUtils and Digester 
are still
part of Struts. I'm more thinking of the Jarakta commons since it is more 
generic in
nature and is has been built on top of things that will be transferred into 
the
Jakarta commons. The other reason why it is better placed in the commons is 
because it
is actually a generic validate/convert/transfer framework which can also 
have an
interesting value for other types of applications, not only for web 
developement. For
example it could be used in a file handler in order to validate each record 
and
produce a message object so be sent to a backend. With the ability to 
generate code
out of the configuration file, performance would be improved by avoiding 
reflection
and could be used for server applications with higher performance 
requirements. Again
lots of things an open source community can do...

François Rey
mailto:francois.rey@capco.com



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>