Re: Using named params
Shlomi Fish wrote:
On Saturday 26 Sep 2009 03:18:35 Steve Bertrand wrote:
I'm concerned about how I slurp in my params. For some reason, it
'feels' very dangerous to me.
Can someone recommend the reading I need to do to ensure that I've been
over the possible ramifications? IOW, I'd like to spend more time
learning about the type of params one should use, when they should be
used, and when certain param types MUST be used (irt standard types, and
refs).
A few notes.
sub captcha {
my $self= shift;
my %params = @_;
My personal preference is to do something like:
{{{
my $params = shift;
}}}
And pass it as a
$self-my_method(
{
%hash,
}
)
This way it is faster and more robust than clobbering the hash into @_.
I gotcha.
If I want someone to use one of my function calls that takes a single
href as a param, would it be fair to say that my understanding is
becoming stronger by thinking that my documentation must be specifically
accurate and easy to understand?
iow, if my documentation is not accurate, then I am responsible for
breakage when incorrect params are passed in. Otherwise, if my doc is
correct (and understandable), then the you're on your own rule
applies...yes?
my $captcha = $params{ -captcha };
my $input = $params{ -input };
You shouldn't use a leading - for the parameter keys. Just do:
my $captcha = $params{captcha};
my $input = $params{input};
- is a remnant from the olden days.
Je comprends.
Now to answer your question - you may wish to look at Params::Validate and
similar modules:
http://search.cpan.org/dist/Params-Validate/
I most certainly will.
Thanks Shlomi,
Steve
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Using named params
On Saturday 26 Sep 2009 03:18:35 Steve Bertrand wrote:
Hi all,
I've read a fair bit about named params, and have been hit by bugs by
overlapping lists into hashes etc.
Below is a method that essentially isn't truly a 'captcha', but is
something I use to 'ensure' that the person clicking the submit button
on a web gui isn't clicking by accident. This was to avoid having to
write intermediary Confirm stages for potentially dangerous actions.
(this is all for internal staff... if they fsck things up after this
stage, they get to rewrite things themselves ;)
Instead of re-writing the code continuously, I finally decided to just
move it to the base class.
I'm concerned about how I slurp in my params. For some reason, it
'feels' very dangerous to me.
Can someone recommend the reading I need to do to ensure that I've been
over the possible ramifications? IOW, I'd like to spend more time
learning about the type of params one should use, when they should be
used, and when certain param types MUST be used (irt standard types, and
refs).
Just to include some code:
A few notes.
sub captcha {
my $self= shift;
my %params = @_;
My personal preference is to do something like:
{{{
my $params = shift;
}}}
And pass it as a
$self-my_method(
{
%hash,
}
)
This way it is faster and more robust than clobbering the hash into @_.
if ( ! %params ) {
my $captcha_length = $self-CAPTCHA_LENGTH();
my $captcha;
for ( 1 .. $captcha_length ) {
$captcha .= int( rand( 10 ));
}
return $captcha;
}
my $captcha = $params{ -captcha };
my $input = $params{ -input };
You shouldn't use a leading - for the parameter keys. Just do:
my $captcha = $params{captcha};
my $input = $params{input};
- is a remnant from the olden days.
Now to answer your question - you may wish to look at Params::Validate and
similar modules:
http://search.cpan.org/dist/Params-Validate/
Regards,
Shlomi Fish
if ( ! $captcha || ! $input ) {
return 1;
}
if ( $captcha eq $input ) {
return $captcha;
}
return 0;
}
Steve
--
-
Shlomi Fish http://www.shlomifish.org/
Why I Love Perl - http://shlom.in/joy-of-perl
Chuck Norris read the entire English Wikipedia in 24 hours. Twice.
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
Using named params
Hi all,
I've read a fair bit about named params, and have been hit by bugs by
overlapping lists into hashes etc.
Below is a method that essentially isn't truly a 'captcha', but is
something I use to 'ensure' that the person clicking the submit button
on a web gui isn't clicking by accident. This was to avoid having to
write intermediary Confirm stages for potentially dangerous actions.
(this is all for internal staff... if they fsck things up after this
stage, they get to rewrite things themselves ;)
Instead of re-writing the code continuously, I finally decided to just
move it to the base class.
I'm concerned about how I slurp in my params. For some reason, it
'feels' very dangerous to me.
Can someone recommend the reading I need to do to ensure that I've been
over the possible ramifications? IOW, I'd like to spend more time
learning about the type of params one should use, when they should be
used, and when certain param types MUST be used (irt standard types, and
refs).
Just to include some code:
sub captcha {
my $self= shift;
my %params = @_;
if ( ! %params ) {
my $captcha_length = $self-CAPTCHA_LENGTH();
my $captcha;
for ( 1 .. $captcha_length ) {
$captcha .= int( rand( 10 ));
}
return $captcha;
}
my $captcha = $params{ -captcha };
my $input = $params{ -input };
if ( ! $captcha || ! $input ) {
return 1;
}
if ( $captcha eq $input ) {
return $captcha;
}
return 0;
}
Steve
smime.p7s
Description: S/MIME Cryptographic Signature
