Operate with Impunity

I am 99.9999% done with a complete rewrite of Validation::Class. I have also written a decent amount of documentation on how you should use the library and why you should use the library.

Within the documentation you can also find a whitepaper that offers insight into the rational behind the framework and why it was created. This project has become a fascination of mine over the past year as I've used it in many personal projects and client projects and have been inspired to continuously innovate.

Currently, the core feature-set consist of self-validating methods, validation profiles, reusable validation rules and templates, pre and post input filtering, class inheritance, automatic array handling, and extensibility (e.g. overriding default error messages, creating custom validators, creating custom input filters and much more). Additionally, I hope to present some of my plans for the future of this project at one of the upcoming conferences (though I'm not as plugged-in as I'd like to be).

For those of you that don't know, lately I've been contracting with Rent.com which is (IMHO) one of the nicest Perl shops around. They have really cool and intelligent people there (this is a non-biased statement, honest). Anyway, I just wanted to mention that during my last trip there (Santa Monica, CA), I had the pleasure of attending a local Perl mongers meetup where I talked-shop with a great group of guys that share my passion for Perl programming, ... which was really cool.

Anyway, I've become a bit of a data validation nut (obviously) and I've been letting it drive app development, and I haven't been disappointed. One of my near-future plans for Validation::Class is to ship with the ability to allow parameters to propagate objects (I'm talking about coercion for you Moose-heads). Validation::Class could effectively become a sweet coercion framework for Moose-based classes (and other object systems).

The following is an excerpt from the whitepaper which you can view here on github for the full-paper. For a simpler introduction with less-fluff, checkout the markdown for Validation::Class::Simple here.


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 understand:

  • what is meant by data validation
  • what the standard validation types are
  • what the common use-cases are were validation applies

First, data validation is the process of auditing a piece of data to ensure it fits a specific criteria. Common data validation checks are:

  • existence checking
  • range checking
  • type checking
  • list-lookup checking
  • dependency checking
  • pattern checking
  • custom validation checking

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:

  • handling arbitrarily and/or dynamically-named parameters
  • handling input for batch-processing
  • handling multi-type parameters (array or scalar depending on context)
  • handling complex conditional validation logic
  • handling multi-variant parameter names (aliases)
  • handling parameter dependencies
  • handling errors (reporting messages, localization, etc)


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.



As a fellow data validation module author (perhaps there should be Acme::CPANAuthors::DataValidation?) it is at least interesting to see the rewrite cycle of Validation::Class :)

And it's most probably just me, but I still think the documentation is a bit dense. There are many concepts to remember and I keep thinking to myself, does data validation need to be this complex? Creating Validation::Class::Simple is a step to the right direction, methinks.

Leave a comment

About Al Newkirk

user-pic ... proud Perl hacker, ask me anything!