I like Data::FormValidator, but I was never happy with the syntax and never used it extensively. Class::CGI basically treats form data as a collection of objects which can be fetched. Further, the various objects which different forms contain can be mixed and matched at will, with ease. Because a lot of the validation stuff is encapsulated in the handler classes responsible for a given object, the programmer's main code is focused on the business concerns.

In short, the code can be as simple as this:

  use Class::CGI
    handlers => {
      customer => 'Class::CGI::Customer',
      date     => 'My::Date::Handler',
    };

  my $cgi  = Class::CGI->new;

  eval {
    my $cust = $cgi->param('customer');
    my $date = $cgi->param('date');
  };

  handle_possible_error($@);

  my $name = $cust->name; # look ma, objects!
  my $year = $date->year;
[download]

There's a bunch of work which gets abstracted away instead of cluttering the code in a large data structure with odd parameters the end user has to figure out.

That's not to say anything is wrong with the Data::FormValidator approach. It's a difference in approach. With DFV, the validation is centralized in the code doing the validating and it validates all of the data. In the Class::CGI approach, each handler is responsible for validating its own data.

Those are just from my rough impressions of DFV, though. If you can show me how clean the top-level code can be, I'd love to see it.

Well, I'm not a veteran DFV user, so I may be stumbling here. But something like this:

use Data::FormValidator;
use Data::FormValidator::Constraints::DateTime qw(to_datetime);
use CGI;

use My::Customer;

my $results = Data::FormValidator->check(
    CGI->new,
    {
        constraints => {
            customer => My::Customer->constraint,
            date     => to_datetime('%D'),
        }
    }
);

if( $results->success )
{
    my $date     = $results->valid('date');
    my $customer = $results->valid('customer');

    $date->year;
    $customer->address->zipcode;
}
[download]

There's no need to inline the profile like that, of course.

&My::Customer::constraint might look like this:

package My::Customer;
use base 'My::Class::DBI';

sub constraint
{
    my $pkg = shift;
    return sub {
        my $value = shift;
        return unless $value =~ /^(\d+)$/;
        return $pkg->retrieve($value);
    };
}
[download]

But, that's all just guesswork on my part (and completely untested). It does show tremendous potential, that I really should try to incorporate in my own work ;)