Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?

proposal for HTML::FormValidator upgrade

by markjugg (Curate)
on May 13, 2001 at 03:41 UTC ( [id://79976]=perlmeditation: print w/replies, xml ) Need Help??

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, 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.

Replies are listed 'Best First'.
Re: proposal for HTML::FormValidator upgrade
by TStanley (Canon) on May 13, 2001 at 04:18 UTC
    As an idea, why don't you also submit the article that you wrote to the Reviews section, and share
    the wealth with the rest of your fellow monks?

    In the end, there can be only one!
      Alright, my review of HTML::FormValidator has now been posted.
Re: proposal for HTML::FormValidator upgrade
by DrZaius (Monk) on May 13, 2001 at 12:00 UTC
    * Easier access from CPAN

    Why is this so bad? Isn't this why we have CPAN in the first place? I like it when modules use other modules -- that means less redundancy and less code.

      HTML::FormValidator has false dependencies-- you don't need any of the other modules that get downloaded when you try to grab just HTML::FormValidator.


HTML::FormValidator changes available in Data::FormValidator
by markjugg (Curate) on Jun 21, 2001 at 03:07 UTC
Invalid field error messages
by Anonymous Monk on May 14, 2001 at 00:39 UTC
    I like most of the ideas. It would be useful to be able to handle "pretty" values of field names, and even better yet, error messages when a field is invalid (e.g. email => "Your e-mail address is invalid", or password => "The passwords that you entered do not match)" I'd also like to see a stand-alone CPAN distribution. I currently include it in Apache::PageKit, but I would unbundle it if there was a good standalone dist.
patch to HTML::FormValidator available
by markjugg (Curate) on May 16, 2001 at 21:04 UTC

    I have now prepared a patch to the code and POD of HTML::FormValidator with the following changes. I would appreciate your review and feedback of these changes. The patched module can be downloaded here:


    • Several updates to the syntax and grammar of the POD
    • Added code and documentation for a procedural interface
    • Added code and docs to allow specifying single item anon. arrays as regular strings
    • Added initial code to support better handling of dynamic form validation. This included added two new routines: constraint_suffix_map and constraint_prefix_map. This allows you map all fields that have a common ending to automatically have a particular constraint applied (for example, validating all fields ending in _zip as zipcodes)
    • added option for "dependency groups"-- when any field in the group is field in, they all become required.

    I have tested all my changes, but I would appreciate your reality checks as well.

    I have a few more features I'd like to add to round out support for dynamic form field generation, but I thought it would be good to send this version out for review already. Here are the features I want to add:


    The basic idea to specific whether some fields are required or optional based on there suffix, prefix, or a regular expression.


Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://79976]
Approved by root
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others sharing their wisdom with the Monastery: (2)
As of 2024-06-22 19:01 GMT
Find Nodes?
    Voting Booth?

    No recent polls found

    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.