Update: Being my first entry here, I didn’t realize that my listed name would be “Curtis Poe”. Everywhere else it’s “Ovid” or “Curtis ‘Ovid’ Poe”. Sorry for the confusion.

Since this is my first blog entry for O’Reilly, an introduction seems to be in order. If you’re involved in the Perl community, you probably know who I am. For those who don’t, I’m one of the authors of the new Perl Hacks book, along with chromatic and Damian Conway. I also sit on the Perl Foundation steering committee and I run the Perl Foundation grant committee. I also have a moderately popular CGI Course online and a fair amount of code released on the CPAN.

I have numerous interests including database design, test-driven development, Web programming and usability. The latter subject has particularly interested me due to the poor state of much code written for the Web. Usability, in my mind, involves focusing about how the end user will really be using your code instead of focusing on functionality. The latter should be driven by the former instead of the other way around. As a classic example, consider the early days of Web programming. Frequently, programmers would grab data from an HTML form and just use the data without bothering to “scrubbing” the data to ensure its validity and safety. This, of course, is a dangerous practice, but it does have a very curious benefit: it allows the programmer to focus on their business needs instead of the nit-picky details involved in scrubbing the detail. As a result, the application development is much faster.

Naturally, this is a terrible trade-off. Numerous Web sites have been hacked due to poor scrubbing. Numerous attempts to provide generic solutions to solve this problem have proven to be confusing and difficult to use. This is often because the developers of these solutions seemed to focus on what needed to be done rather than making it as easy as possible for the programmer to use the code (though I suspect the developers would argue otherwise). As a result, programmers often either skip the data scrubbing or they embed all of the scrubbing in their code and this can obscure the business problem they’re trying to solve. What’s worse, by embedding the scrubbing in their code, they’re often repeating this scrubbing throughout their code. If they need to change how they validate data, they won’t be very happy.

To deal with this, I’ve started writing Class::CGI. Though still alpha code, it’s an experiment with trying to provide the data “scrubbing” but abstract it away into “handlers” which allows the developer to focus on solving their business problem rather than the fiddly bits. It looks something like this:

  use Class::CGI
      handlers => {
          date     => 'Class::CGI::DateTime',
          email    => 'Class::CGI::Email::Valid',
          customer => 'My::Customer::Handler'
      };

  my $cgi = Class::CGI->new;
  $cgi->required(qw/customer date/);

  my $customer = $cgi->param('customer');
  my $email    = $cgi->param('email');
  my $date     = $cgi->param('date');

  if ( $cgi->errors ) { ... }

That’s the basic pattern of how Class::CGI should be used. The date is actually returned as a DateTime object, but only if all required fields (day, month and year) are present. The email address is automatically checked for validity and the customer might be a customer record you’ve pulled from a database. In other words, an awful lot of grunt work has been hidden away behind the scenes and you, the programmer, can focus on getting your job done.

While the technical details are outside of what I want to focus on here, the basic implementation is a mediator pattern. By doing an awful lot of Web programming and knowing the common problems that programmers face when writing Web-based code, we provide a simple interface which makes programming easier. Further, it allows the application code to focus on the business problem you’re trying to solve and should make the code easier to read and maintain. Whether or not Class::CGI becomes successful is still up in the air, but so far I’ve found that programming with it makes for clean, easy to use code. And that’s because I focused on what the programmer needs instead of what the program needs.