Zen and the art of Castle maintenance

A few weeks ago I introduced a new project o Castle’s trunk: Castle.Components.Validator. This was supposed to go to the Castle.Core, but to prevent the third world war from starting on castle mailing list, I decided to go with a separated assembly. This project has no dependencies, and can be used on a variety of projects and environments. I’ll try to explain the basics here and see what happens.

What itchy it scratches

The project’s goal was to create a thin, lightweight and flexible validation framework. Validation rules are – conceptually – attached to Types. The standard way is to use attributes, but they are not obligatory.

How does it work

The main entity is the ValidatorRunner, and it requires an IValidatorRegistry instance. The registry keeps the set of validators associated with a type and its properties. Out of box there’s a CachedValidationRegistry implementation which uses reflection. If you’re a xml fanatic, you can create a IValidatorRegistry implementation that reads from a xml file.

For performance reasons you should only have a single IValidatorRegistry instance. The ValidatorRunner should be created per activity, as it is stateful.

Using it

To use the Validator you just need to instantiate the runner and use one of the IsValid overload:

ValidatorRunner runner = new ValidatorRunner(new CachedValidationRegistry());

if (runner.IsValid(customer))
{
	// do something with customer
}
else
{
	MessageBox.Show("Whoops!");
}

After invoking the IsValid you can use the GetErrorSummary(instance) to grab a detailed list of what went wrong.

The validators

A validator is just an ordinary class that implements the IValidator attribute. The important method is the IsValid. The code for NonEmptyValidator follows:

public class NonEmptyValidator : AbstractValidator
{
	public override bool IsValid(object instance, object fieldValue)
	{
		return fieldValue != null && fieldValue.ToString().Length != 0;
	}

	..
}

The attributes

If you create a new validator, you’d usually use an attribute to associate it with a property. The attribute is required to implement IValidatorBuilder. The implementation for ValidateNonEmptyAttribute follows:

public class ValidateNonEmptyAttribute : AbstractValidationAttribute
{
	public ValidateNonEmptyAttribute()
	{
	}

	public override IValidator Build()
	{
		IValidator validator = new NonEmptyValidator();
		
		ConfigureValidatorMessage(validator);
		
		return validator;
	}
}

i18n support

The default error messages are available in english, portuguese and dutch, using satellite assemblies. I considered an approach to have custom error messages and yet “localizable” ones, but gave up after 20 minutes. The best I could think of was using a special string that indicates an assembly should be loaded. Something like

public class Customer
{
	[ValidateNonEmpty(LocalizableMessage='name_is_required')]
	public string Name
	{
		..
	}
}

Javascript integration

The validator can declare that they support web validation. That means that a validator can configure a js library to perform the same validation it is supposed to perform. This is done using the IWebValidationGenerator, which exposes operation that most of the js validation libraries implement.

For example, here is a code snippet from the NonEmptyValidator:

public override bool SupportsWebValidation
{
	get { return true; }
}

public override void ApplyWebValidation(WebValidationConfiguration config, InputElementType inputType,
										IWebValidationGenerator generator, IDictionary attributes)
{
	generator.SetAsRequired(BuildErrorMessage());
}

It is up to the implementation of IWebValidationGenerator to attach the html to the element attributes. MonoRail has two implementations: for fValidate and for the Prototype Validation.

… and more!

Some validations may make sense for a situation, and be totally unnecessary in other. That’s why you can associate phases with validations:

[ValidateSameAs("Password", RunWhen=RunWhen.Insert)]
public string Confirmation
{
	get { return confirmation; }
	set { confirmation = value; }
}

The possible phases are: everytime, insert, update and custom.

When you use the runner, you can tell it to restrict the validation to a specific phase:

bool isValid = runner.IsValid(customer, RunWhen.Custom);

You can also define an execution order:

[ValidateNonEmpty(ExecutionOrder=1)]
[ValidateLength(3, 12, "Invalid password length", ExecutionOrder=2)]
public string Password
{
	get { return pwd; }
	set { pwd = value; }
}

A friendly name for a property may also be handy:

[ValidateNonEmpty(FriendlyName="CoResponsible user")]
public string CoResponsibleUserName
{
	get { return secondUser; }
	set { secondUser = value; }
}

The class diagram

If you want to give it a try, grab Castle’s source, or browse the source code.

Have fun!