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.