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.
-
Are you posting in the right place? Check out Where do I post X? to know for sure.
-
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
<u> <ul>
-
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
intervention).
-
Want more info? How to link
or How to display code and escape characters
are good places to start.
|
|