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;
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.
Cheers,
Ovid
New address of my CGI Course.
In reply to Re^2: RFC: Class::CGI
by Ovid
in thread RFC: Class::CGI
by Ovid
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |