Hello! I've been using HTML::FormValidator on a regular basis now, and I really like it's basic function as a module. I wrote up an example of how I use it here.

Now I've realized there are a number of ways it could be improved. Since the current maintainer has been initially unresponsive to my queries, I plan to go ahead with creating a significant patch to the module. I'd like to ask ya'll monks for feedback on the following module design changes:

• Provide a procedural interface -- HTML::FormValidator provides a number of handy regular expressions. It provides "filters" which modify strings in useful ways, such as 'trim' which trims off leading and trailing whitespace. It also provides "validators", which let you know if a string matches a common pattern, like an American phone number. Unfortunately, you can only use these by either using the documented OO interface, or calling a function explicitly like HTML::FormValidator::filter_trim. I propose adding the ability to export all the filters and validator routines for procedural use. For example, If a field contained a list of comma seperated email addresses, I would easily be able to call the 'validator_email' function within a loop to see if they matched. I would do this by providing two groups in @EXPORT_OK:
  :filters :validators
• allows strings in place of single element anonymous arrays. In a few places HTML::FormValidator expects anonymous arrays as values. Similar to CGI.pm, I'd like to add support for simply using a string when you only need to supply one value. Here are some examples that illustrate this point:

  ### current style: single values must be anon arrays
  
  my $validator = new HTML::FormValidator(
   {
    form => {
     required => [ 'foo' ],
     optional => [ 'zoo' ],
     filters  => [ 'trim' ], 
    }
   }
  );
  
  ### proposed style, single values can be scalars
  
  my $validator = new HTML::FormValidator({
   form => {
    required => 'foo',
    optional => 'zoo',
    filters  => 'trim', 
   }
  });
   

• Handle "pretty" values of field names somehow This is area I'd like some suggestions for. The most common thing I do with HTML::FormValidator is to return a list of fields that have missing or invalid input. Since I don't expect users to understand what my field names mean, I use a %pretty hash to map the form field names to something "Pretty" that users could be expected to grok. I'd like to incorporate defining a hash like this into the HTML::FormValidator interface, but I'm sure of the best way to fit it in. The primary issue I think is that one of the hashes that is returned by the validate function maps the form field names to their values. To support "pretty" names, we also need to be able to map the form field names to the pretty version. Proposals?
• Better validation of dynamicly generate form fields. Fairly frequently I need to generate form field names dynamically, such as when a form field name is tied to a row I just pulled out of a database. Currently to validate dynamic form fields, you would need to loop over the form data using the logic "if this form field matches this pattern, than validate it this way". I'd like formalize this process and make it easier for HTML::FormValidator to handle this case. My proposal is to allow people to to tie a certain validation scheme to particular prefix or suffix of a field name. For example:

  #### an example of how you can currently map the suffix of a field name to a constraint
  #### This means that all fields that end in _usps_abbrev must a valid US state and 
  ####   all fields that end in _phone must be a valid US phone number 
   my %constraints; 
   foreach my $key (keys %FORM) {
    $constraint{$key} = 'state' if $key =~ m/_usps_abbrev$/;
    $constraint{$key} = 'american_phone' if $key =~ m/_phone$/;
   }
   
   my $validator = new HTML::FormValidator({
    form => {
     constraints => \%constraints,
    }
   });
   
  #### same thing, using proposed syntax for constraint suffix mapping:  
   
   my $validator = new HTML::FormValidator({
    form => {
     constraint_suffix_map => {
      _usps_abbrev => 'state',
      _phone   => 'american_phone'
     }
    }
   });
  

• Add support for "dependency groups" -- Another kind of validation I want to do fairly frequently with HTML::FormValidator is cause the presence of one field being field in to require a whole group of fields being field in. For example, perhaps in a form the password and password confirmation fields are optional, but if one if field in, you need need both of them to be filled in. I propose supporting this by using using a hash a whose values are anonymous arrays. For example:

  dependency_groups => {
       password_group   => [qw/password password_confirmation/],
  }
   

  An array of arrays would do most of what we want, but by using hashes, I think we get a form of self-documentation and it should also be easier to manipulate the structure dynamically since you can say "add an item to the password group" instead of "add an item to the first dependency group".
• Easier access from CPAN -- Currently you can't grab HTML::FormValidator directly from CPAN, it will try to install a slew of packages that it doesn't actually depend on if you do. What does it take to untangle this, so HTML::FormValidator is available on it's own?
• Can we leverage other modules? -- Date::Calc has nice check_date validation function, which expects input as $year,$month,$day. Is there a way that a call to this could usefully be integrated with HTML::FormValidator's interface? Rexexp::Common is similar to HTML::FormValidator in that it provides shortcuts for common regular expressions. Is there a useful way that HTML::FormValidator could outsource some of it's regular expression work to Regexp::Common in a useful way?

update 5/13/01: clarified note about CPAN, retracted idea about using hashes directly in constructor.