I'm trying to inherit the RegularExpressionAttribute
to improve reusability with validating SSNs.
I have the following model:
public class FooModel
{
[RegularExpression(@"^(?!000)(?!666)(?!9[0-9][0-9])\d{3}[- ]?(?!00)\d{2}[- ]?(?!0000)\d{4}$", ErrorMessage = "The SSN you entered is invalid. If you do not have this number please leave the field blank")]
public string Ssn { get; set; }
}
which will validate correctly on the client and server. I wanted to encapsulate that lengthy regular expression into its own validation attribute like so:
public class SsnAttribute : RegularExpressionAttribute
{
public SsnAttribute() : base(@"^(?!000)(?!666)(?!9[0-9][0-9])\d{3}[- ]?(?!00)\d{2}[- ]?(?!0000)\d{4}$")
{
ErrorMessage = "SSN is invalid";
}
}
Then I changed my FooModel
like so:
public class FooModel
{
[Ssn(ErrorMessage = "The SSN you entered is invalid. If you do not have this number please leave the field blank")]
public string Ssn { get; set; }
}
Now the validation doesn't render the unobtrusive data attributes on the client. I'm not quite sure as to why, since this seems like the two should essentially be the same thing.
Any suggestions?
In your
Application_Start
add the following line to associate an adapater to your custom attribute that will be responsible for emitting the client side validation attributes:The reason why you need this is the way
RegularExpressionAttribute
is implemented. It doesn't implementIClientValidatable
interface but it rather has aRegularExpressionAttributeAdapter
which is associated to it.In your case you have a custom attribute that derives from
RegularExpressionAttribute
but your attribute doesn't implement theIClientValidatable
interface in order for client validation to work nor does it have an attribute adapter associated to it (contrary to its parent class). So yourSsnAttribute
should either implement theIClientValidatable
interface or have an adapter associated as suggested previously in my answer.This being said personally I don't see much point in implementing this custom validation attribute. A constant might be sufficient in this case:
and then:
seems quite readable.