Jos Boumans got back to me about the suggestions I sent him. He has kindly made the following changes
1) Convert all keys to lowercase
I didn't like the idea that the module automatically returned all parameter names in lower case. However, as Jos had a need for this he wants to keep that as default, and has added the global variable $Params::Check::PRESERVE_CASE, which will be set to 0. I'm grateful for the addition, but still consider anything that changes what was input, should be at the users descretion. Plus although the default is TO_LOWER and we can PRESERVE_CASE, what if the user wanted TO_UPPER?
2) Weed out arguments that are not supported and warn about them to the user
Jos has now changed the following:
17c19 < $VERBOSE = 1; --- > $VERBOSE = $^W ? 1 : 0;
Which is a fairer setting. However, it suddenly made me realise we were coming at this module from two very different perspectives.
Jos also wanted clarification as to what I meant by my suffix suggestion. Because I spotted the similarities between the module and my code, I'd assumed Jos was using it in the same way. However, now I don't think he is. Logically the name Params::Check suggests the module is just checking parameters, subroutine parameters. However, my code is checking CGI parameters, which is why the two issues above and the suffix suggestion are at odds with Jos's thinking.
I'll be writing to Jos with a better explanation of where I'm coming from, so hopefully he'll be able to see why the suffix suggestion would be a good idea. It also goes to prove that Params::Check is a very useful module being generic enough for two purposes, and perhaps others. Now I'm even more gutted I didn't think to do this first .... d'oh :)
Re:Params::Validate
barbie on 2003-05-13T09:07:23
I hadn't until I found Params::Check, but Params::Validate is more aimed at function paramaters, whereas I use CGI parameters. Params::Check fits better with validating CGI parameters and I personally prefer the interface.There is also Data::FormValidator, but that only really deals with the existance of form fields in a form.
All three are very close and could reasonably be amalgamated into one generic module, but I doubt that'll happen.
Re:Params::Validate
autarch on 2003-05-13T15:24:57
Patches welcome;) Re:Params::Validate
barbie on 2003-05-13T16:54:11
I seem to have an ability for spotting a bigger picture than module authors invisaged:) The problem with providing patches in this senario, is which module gets them? As I see it these three modules all provide a variation of validation for parameters. All three have little tricks the others don't have and all three could be coerced to validate the same set of parameters (whether functional or CGI), although Data::FieldValidation doesn't validate the contents based on rules.
They all have their good points, but it would be nice if they could amalgate into one REALLY cool module. The big downside would be that two module authors would have to defer maintenance to another.
If I ever get the time, I might try and write some patches and send them out to you all. There might be some good ideas in there, probably some bad ones, but hopefully we could end up with one hellva generic parameter validation module.
It's on my TODO list
;) Re:Params::Validate
autarch on 2003-05-13T18:02:33
Actually, Params::Check is really similar to Params::Validate, it just highlights a different set of features in the docs.
P::Validate offers the "allow unknown", and "strip leading dashes" features of P::Check. It also can optionally ignore case. Adding an option to convert keys to upper/lower case would be easy. It already handles defaults. It can die on unknown args, and adding support for just warning wouldn't be too hard.
As to the validation pieces of P::Check, that can all be done via the P::Validate callbacks or regex validation.
I don't think the author of P::Check looked at P::Validate closely enough before uploading. P::Validate does 90% of the same things P::Check does, with a pretty similar API even. And P::Validate has the additional advantage of offering an optimized XS version.
Maybe someone (probably not me) should politely suggest that Kane withdraw P::Check and submit some patches for P::Validate.Re:Params::Validate
kane on 2003-05-14T07:46:52
I'm actually not totally oblivious;) What you see happening here is abstracting out code from cpanplus (that's been in the source in one shape or the other for a year and a half), so they can be used in other (possibly related) projects.
As I mentioned to barbie, the design decisions for P::C are very selfish, since CPANPLUS relies on it heavily and I pretty much implement into it any or all features CPANPLUS might require, hence releasing it as a module owned by me.
I'm not at all opposed to merging the efforts, but as stated above, my primary concern with this module (and a few more i added), are they be fully compatible wtih my views of it.
And yes, i'm aware of how elitist this sounds;)
Maybe to let you do what you want?
# Emulate $Params::Check::STRIP_LEADING_DASHES $Params::Check::NORMALISE_KEY = sub { s/^-// }; # Combine $Params::Check::STRIP_LEADING_DASHES # and to lowercase $Params::Check::NORMALISE_KEY = sub { lc ; s/^-// }; # Example how to add it to the Params::Check source if ( ref $NORMALISE_KEY eq 'CODE' ){ $key = $NORMALISE_KEY->( $key ); } else { croak "$Params::Check::NORMALISE_KEY must be a coderef"; }You get the idea
Clayton
Re:Needs something more generic
tex on 2003-05-13T17:41:30
<p>Poorly formatted code...</p>
# Emulate $Params::Check::STRIP_LEADING_DASHES
$Params::Check::NORMALISE_KEY = sub { s/^-// };
# Combine $Params::Check::STRIP_LEADING_DASHES
# and to lowercase
$Params::Check::NORMALISE_KEY = sub { lc ; s/^-// };
# Example of how to add it to the Params::Check source
if ( ref $NORMALISE_KEY eq 'CODE' ){
$key = $NORMALISE_KEY->( $key );
} else {
croak "$Params::Check::NORMALISE_KEY must be a coderef";
}
ClaytonRe:Needs something more generic
barbie on 2003-05-13T17:54:08
Will look into that. Thanks.
