Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2004-06-04 16:00:46
|
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=FCrgen H=F6ller 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 |
|
From: Seth L. <se...@eh...> - 2004-06-04 19:55:12
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 | 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. I just looked through their CVS, and didn't see a FieldChecks class. They are currenly on 1.1 and have a 1.2 waiting in the wings. | 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? No objections to building against a snapshot. We do it for attributes anyway. :) | official support? Of course, we could simply leave it in the sandbox | for the time being... I'm fine with that, as long as it's still available. We used it to make our migration from struts to spring very easy. Also, until the attributes/declarative validation stuff appears, the commons-validator is all we have for that type of work. Seth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3-nr1 (Windows XP) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAwNObKZsFSwtW+wIRAhSYAJ0eW/g4E35QakNH5T5TBWcSNwW/twCfWan3 N9fHdcQahIPIWRQzQMqpcv0= =tiax -----END PGP SIGNATURE----- |
|
From: Daniel M. <mi...@pa...> - 2004-06-05 20:02:21
|
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
|
