Enterprise Library Valiators - beware of lowerBoundType in StringLengthValidator
I was using StringLength Validator provided by Enterprise Library Validation Block (integration with ASP.NET).
I started with attributes based validation specification -:
[StringLengthValidator(2, 10)]
public string Name
{
get{}
set{}
}
and it worked fine. It gave validation warning when string of length 1 is entered in the ASP.ET text box.
Later I removed these attributes and moved this validation to xml file (for the corresponding business class and RuleSet "A" and "A" is the default ruleset):
messageTemplateResourceName="" messageTemplateResourceType=""
tag="" type="Microsoft.Practices.EnterpriseLibrary.Validation.Validators.StringLengthValidator, Microsoft.Practices.EnterpriseLibrary.Validation, Version=3.1.0.0, Culture=neutral, PublicKeyToken=null"
name="String Length Validator" />
Suddenly, my validations stopped working. There was no validation error when I used string of length = 1 .
The first suspect was whether the config file was loading correctly. I checked multiple times - I removed and re-added validations again EL configurator, closed reopened solution, but the problem did persist.
Next suspect was - am I choosing the correct type in EL configurator?. That too was correct.
Next, I also tried hardfixing the SpecificationSource="Configuration" from "both" in PropertyProxyValidator - thinking that EL was not reading validations from Configuration file. This too did not work.
After long hours, I decided - why not use EL sources to debug this? I added corresponding EL projects to the solution, changed references to use these and started debugging (the PublicKeyToken which was added by the EL configurator disturbed me a lot, but I soon got over it). Deep inside, I realized the nculprit - the code was not attempting to validate the lowerBound since lowerBoundType was false :-). A simple mistake that took me hours to debug.
I guess that the default value of lowerBoundType is "Ignore" because mostly people do not like to have lower bound. However, a normal human who uses [StringLengthValidator(2, 10)], will not be intuted that while converting the validators to XML based ones, he must use either "Implicit" or "Explicit" explicitly, or else validations will not work. Wonder why EL team have not kept Implict as the default option.
Comments
Post a Comment