>From: "Craig McClanahan" <[EMAIL PROTECTED]> > > While reviewing the work done so far on the Shale Validator integration in > preparation for the changes described in SHALE-340, I ran into an issue > that > is noted in the comments on SHALE-36 but needs to be explicitly decided. > If > you have explicitly defined a converter (or JSF can do it for you > implicitly > because the value is bound to a bean property with a known type), then the > "value" that is passed in to the validate() method will already have been > converted. This will lead to problems when calling methods like > GenericValidator.isInt() for an argument being validated as an integer, > which assumes the incoming value is a String. > > What I propose is that the validate() methods in shale-validator should > ignore the "value" parameter to the validate() method. Instead, they > should > cast the UIComponent to a n EditableValueHolder, and then call > getSubmittedValue() on that to get the value to be validated. This seems > much more in line with the assumptions Commons Validator makes (it is > validating strings). The potential cost of this is that the format > validation done here is basically wasted if a converter has already been > applied, but it allows the validation logic to not worry about this kind > of > thing. > > Thoughts? >
If we use the submitted value, we are assuming that the converter is only handling simple data type conversion. The converter might be stripping out "$" or ",". That's why it uses the converted type that converts it to a string and then to the target type. I guess we could assume that they are not doing anything tricky with type conversion and use the submitted value but that's why that decision was made. > Craig Gary
