This whitepaper will serves as a guide to help readers understand the common data validation issues as well as the the rationale and various usage scenarios for Validation::Class.

Data validation is an important aspect of every application yet it is often overlooked or neglected.
Data validation should be thought of as your data input firewall,
a layer that exist between the user of your application and the application's business objects.

The most common application security weakness is the failure to properly validate input from the client or environment.
Data validation is important because it provides security,
it allows you to ensure user supplied data is formatted properly,
is within length boundaries,
contains permitted characters and adheres to business rules.

To understand the problem domain we need to first ask ourselves:

* what is data validation? and ... is that what I've been doing?
* what are the common data validation requirements?
* what are the common use-cases where validation becomes tricky?

Data validation is the process of auditing a piece of data to ensure it fits a specific criteria. Standard data validation requirements are:

Typically when designing an application we tend to name input parameters in an arbitrarily fashion and validate the same data at various stages during a program's execution (duplicating logic and validation routines) in various places in the application stack. This approach is inefficient and prone to bugs, inconsistencies and security problems.

Data can be submitted to an application in various formats and it is not always ideal, and the option to pre-format the data is not always ideal or even possible. A few common use-cases were validation is required and often fails (in a big big way) are as follows:

A better approach to data validation is to first consider each parameter hitting your application as a transmission fitting a very specific criteria and construct a data validation layer that operates with that in mind (e.g. exactly like a network firewall). Your data validation rules should act as filters which will accept or reject and format the transmission for use within your application.

A proper validation framework should allow you to model data and construct validation objects with a focus on structuring rules, reusing common declarations, defining input filters and validating data. Its main purpose should be to properly handle data input errors. It's ulterior motive should be to ensure consistency and promote reuse of data validation rules.

Validation::Class was built around the concept of compartmentalization and re-use. That premise gave birth to the idea of persistent data validation rules which exist in a class configuration which is associated with a class which acts as a validation domain for related validation rules.

Validation classes derived from Validation::Class are typically configured using the Validation::Class sugar functions (or keywords). Validation classes are typically defined using the following keywords:

* field - a data validation rule that matches an input parameter
* mixin - a configuration template which can be merged with a field
* directive - a field/mixin rule corresponding to a directive class name
* filter - a custom filtering routine which transforms a field value
* method - a self-validating sub-routine w/ associated validation profile

A data validation framework exists to handle failures, it is its main function and purpose, in-fact, the difference between a validation framework and a type-constraint system is how it responds to errors.

There are generally two types of errors that occur in an application, user-errors which are expected and should be handled and reported so that a user can correct the problem, and system-errors which are unexpected and should cause the application to terminate and/or handling the exception. Exception handling is the process of responding to the occurrence, during computation, of exceptions (anomalous or exceptional situations).

User errors and system errors are poplar opposites. It is not always desired and/or appropriate to crash from a failure to validate user input. The following examples should clearly display how Validation::Class addresses key pain-points and handles common use-cases were validation is usually quite arduous.

The following screencast and/or slideshow explains what Validation::Class is, why it was created, and what it has to offer. Please note that this screencast and slideshow was created many moons ago and some of its content may be a bit outdated.