RE: [Springframework-developer] Commons Validator support

[Daniel M. <mi...@pa...>]

Juergen, all,

I agree that those classes copied and pasted from Struts are messy. I didn't
rewrite them because I haven't felt like getting dirty when I wasn't at work
lately :)

I'm not sure what is available in CV 1.1 though. It's been a long time since
I looked at that. I had originally tried to use it but changed my mind
because it was marked "alpha". As far as I know, this is still the case (CV
is at 1.2 now too). At any rate, is it going to be much easier to integrate
Spring and CV cleanly with v1.2 than with 1.0.2?

I totally agree that the CV project should maintain the FieldChecks class.
Currently it is the opposite; FieldChecks is the class that Spring is
supposed to maintain to provide the interface between CV and
Errors.rejectValue. It would be nice if the CV project would abstract the
framework-specific part of the FieldChecks class out to a simple interface
something like this:

public interface ValidationErrorPublisher {
    /**
     * Framework-specific error message publisher.
     *
     * @param field The field to be validated.
     * @param va The ValidatorAction for which the error occurred.
     * @param parameters Parameters passed to the Validator via
setParameter().
     */
    void publishError(Field field, ValidatorAction va, Map parameters);
}

Then we could just maintain an implementation of this instead of the entire
FieldChecks class with all of its validation code. That would take care of
FieldChecks--AND a standard version of validation-rules.xml could even be
provided by CV because frameworks would no longer have to tell CV how to
call each validation rule.

I also agree that JavascriptValidatorTag should be maintained by CV. They
should at least provide a version of this class with abstract dependency
retrieval methods (getValidatorResources and getMessage) so that a framework
could simply extend the abstract class to provide this tag.

As it stands, the commons-validator was never really fully abstracted when
it was moved from Struts to its own project. Consequently, we deal with
these headaches to make it integrate into Spring. I think I need to talk to
the CV developers to get some of these things factored out once and for all.
Hmmm...sounds like a giant undertaking...

In the mean time, could a zip file containing Spring-CommonsValidator.jar,
validator-rules.xml, an example validation.xml, and an example spring
config.xml be hosted on springframework.org? It is totally stand-alone as
is. I believe all of the xml files are in the sandbox. If not, I can supply
them.

Thoughts, comments?

Thanks,
Daniel


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of jürgen höller [werk3AT]
Sent: Friday, June 04, 2004 12:00 PM
To: spr...@li...
Subject: [Springframework-developer] Commons Validator support


Matt, Daniel, Keith,

I've just reviewed the Commons Validator support in the sandbox, and I have
come to the conclusion that it is not ready for prime time yet. This is not
the fault of the integration classes; it's rather the fault of Commons
Validator 1.0.2's scope.

I object to shipping a 31 KB FieldChecks class and a 24 KB
JavascriptValidatorTag class that are copied-and-pasted from Struts. Generic
versions of those should really be part of Commons Validator itself, and I
understand that they might be as of Commons Validator 1.1. If we'd ship
modified copies ourselves, we'd have to maintain them - this is certainly
not worthwhile.

How useful is our Commons Validator integration without FieldChecks and
JavascriptValidatorTag? I guess it would be too bare-bones without them...
So it seems to me that we won't be able to ship proper Commons Validator
integration (i.e. without copying-and-pasting) before Commons Validator 1.1.
Or should we try to build on a current Commons Validator snapshot?

Thoughts? Opinions? Suggestions on how to make the current version available
outside of the standard Spring distribution, without official support? Of
course, we could simply leave it in the sandbox for the time being...

Juergen


DI Jürgen Höller
Senior System Architect
______________________________________

werk3ATS - division systementwicklung
werk3AT informations- und mediensysteme

europaplatz 4
A - 4020 linz

t.  +43 (0) 732 71 65 29 502
f.  +43 (0) 732 71 65 29 3
mailto:jue...@we...
http://www.werk3at.com
______________________________________
werk3ATS - WIR ENTWICKELN ERFOLG


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer