|
0 |
# NAME
|
|
1 |
|
|
2 |
Params::Validate - Validate method/function parameters
|
|
3 |
|
|
4 |
# VERSION
|
|
5 |
|
|
6 |
version 1.13
|
|
7 |
|
|
8 |
# SYNOPSIS
|
|
9 |
|
|
10 |
use Params::Validate qw(:all);
|
|
11 |
|
|
12 |
# takes named params (hash or hashref)
|
|
13 |
sub foo {
|
|
14 |
validate(
|
|
15 |
@_, {
|
|
16 |
foo => 1, # mandatory
|
|
17 |
bar => 0, # optional
|
|
18 |
}
|
|
19 |
);
|
|
20 |
}
|
|
21 |
|
|
22 |
# takes positional params
|
|
23 |
sub bar {
|
|
24 |
# first two are mandatory, third is optional
|
|
25 |
validate_pos( @_, 1, 1, 0 );
|
|
26 |
}
|
|
27 |
|
|
28 |
sub foo2 {
|
|
29 |
validate(
|
|
30 |
@_, {
|
|
31 |
foo =>
|
|
32 |
# specify a type
|
|
33 |
{ type => ARRAYREF },
|
|
34 |
bar =>
|
|
35 |
# specify an interface
|
|
36 |
{ can => [ 'print', 'flush', 'frobnicate' ] },
|
|
37 |
baz => {
|
|
38 |
type => SCALAR, # a scalar ...
|
|
39 |
# ... that is a plain integer ...
|
|
40 |
regex => qr/^\d+$/,
|
|
41 |
callbacks => { # ... and smaller than 90
|
|
42 |
'less than 90' => sub { shift() < 90 },
|
|
43 |
},
|
|
44 |
}
|
|
45 |
}
|
|
46 |
);
|
|
47 |
}
|
|
48 |
|
|
49 |
sub with_defaults {
|
|
50 |
my %p = validate(
|
|
51 |
@_, {
|
|
52 |
# required
|
|
53 |
foo => 1,
|
|
54 |
# $p{bar} will be 99 if bar is not given. bar is now
|
|
55 |
# optional.
|
|
56 |
bar => { default => 99 }
|
|
57 |
}
|
|
58 |
);
|
|
59 |
}
|
|
60 |
|
|
61 |
sub pos_with_defaults {
|
|
62 |
my @p = validate_pos( @_, 1, { default => 99 } );
|
|
63 |
}
|
|
64 |
|
|
65 |
sub sets_options_on_call {
|
|
66 |
my %p = validate_with(
|
|
67 |
params => \@_,
|
|
68 |
spec => { foo => { type => SCALAR, default => 2 } },
|
|
69 |
normalize_keys => sub { $_[0] =~ s/^-//; lc $_[0] },
|
|
70 |
);
|
|
71 |
}
|
|
72 |
|
|
73 |
# DESCRIPTION
|
|
74 |
|
|
75 |
The Params::Validate module allows you to validate method or function
|
|
76 |
call parameters to an arbitrary level of specificity. At the simplest
|
|
77 |
level, it is capable of validating the required parameters were given
|
|
78 |
and that no unspecified additional parameters were passed in.
|
|
79 |
|
|
80 |
It is also capable of determining that a parameter is of a specific
|
|
81 |
type, that it is an object of a certain class hierarchy, that it
|
|
82 |
possesses certain methods, or applying validation callbacks to
|
|
83 |
arguments.
|
|
84 |
|
|
85 |
## EXPORT
|
|
86 |
|
|
87 |
The module always exports the `validate()` and `validate_pos()`
|
|
88 |
functions.
|
|
89 |
|
|
90 |
It also has an additional function available for export,
|
|
91 |
`validate_with`, which can be used to validate any type of
|
|
92 |
parameters, and set various options on a per-invocation basis.
|
|
93 |
|
|
94 |
In addition, it can export the following constants, which are used as
|
|
95 |
part of the type checking. These are `SCALAR`, `ARRAYREF`,
|
|
96 |
`HASHREF`, `CODEREF`, `GLOB`, `GLOBREF`, and `SCALARREF`,
|
|
97 |
`UNDEF`, `OBJECT`, `BOOLEAN`, and `HANDLE`. These are explained
|
|
98 |
in the section on [Type Validation](https://metacpan.org/pod/Params::Validate#Type-Validation).
|
|
99 |
|
|
100 |
The constants are available via the export tag `:types`. There is
|
|
101 |
also an `:all` tag which includes all of the constants as well as the
|
|
102 |
`validation_options()` function.
|
|
103 |
|
|
104 |
# PARAMETER VALIDATION
|
|
105 |
|
|
106 |
The validation mechanisms provided by this module can handle both
|
|
107 |
named or positional parameters. For the most part, the same features
|
|
108 |
are available for each. The biggest difference is the way that the
|
|
109 |
validation specification is given to the relevant subroutine. The
|
|
110 |
other difference is in the error messages produced when validation
|
|
111 |
checks fail.
|
|
112 |
|
|
113 |
When handling named parameters, the module will accept either a hash
|
|
114 |
or a hash reference.
|
|
115 |
|
|
116 |
Subroutines expecting named parameters should call the `validate()`
|
|
117 |
subroutine like this:
|
|
118 |
|
|
119 |
validate(
|
|
120 |
@_, {
|
|
121 |
parameter1 => validation spec,
|
|
122 |
parameter2 => validation spec,
|
|
123 |
...
|
|
124 |
}
|
|
125 |
);
|
|
126 |
|
|
127 |
Subroutines expecting positional parameters should call the
|
|
128 |
`validate_pos()` subroutine like this:
|
|
129 |
|
|
130 |
validate_pos( @_, { validation spec }, { validation spec } );
|
|
131 |
|
|
132 |
## Mandatory/Optional Parameters
|
|
133 |
|
|
134 |
If you just want to specify that some parameters are mandatory and
|
|
135 |
others are optional, this can be done very simply.
|
|
136 |
|
|
137 |
For a subroutine expecting named parameters, you would do this:
|
|
138 |
|
|
139 |
validate( @_, { foo => 1, bar => 1, baz => 0 } );
|
|
140 |
|
|
141 |
This says that the "foo" and "bar" parameters are mandatory and that
|
|
142 |
the "baz" parameter is optional. The presence of any other
|
|
143 |
parameters will cause an error.
|
|
144 |
|
|
145 |
For a subroutine expecting positional parameters, you would do this:
|
|
146 |
|
|
147 |
validate_pos( @_, 1, 1, 0, 0 );
|
|
148 |
|
|
149 |
This says that you expect at least 2 and no more than 4 parameters.
|
|
150 |
If you have a subroutine that has a minimum number of parameters but
|
|
151 |
can take any maximum number, you can do this:
|
|
152 |
|
|
153 |
validate_pos( @_, 1, 1, (0) x (@_ - 2) );
|
|
154 |
|
|
155 |
This will always be valid as long as at least two parameters are
|
|
156 |
given. A similar construct could be used for the more complex
|
|
157 |
validation parameters described further on.
|
|
158 |
|
|
159 |
Please note that this:
|
|
160 |
|
|
161 |
validate_pos( @_, 1, 1, 0, 1, 1 );
|
|
162 |
|
|
163 |
makes absolutely no sense, so don't do it. Any zeros must come at the
|
|
164 |
end of the validation specification.
|
|
165 |
|
|
166 |
In addition, if you specify that a parameter can have a default, then
|
|
167 |
it is considered optional.
|
|
168 |
|
|
169 |
## Type Validation
|
|
170 |
|
|
171 |
This module supports the following simple types, which can be
|
|
172 |
[exported as constants](#export):
|
|
173 |
|
|
174 |
- SCALAR
|
|
175 |
|
|
176 |
A scalar which is not a reference, such as `10` or `'hello'`. A
|
|
177 |
parameter that is undefined is **not** treated as a scalar. If you
|
|
178 |
want to allow undefined values, you will have to specify `SCALAR |
|
|
179 |
UNDEF`.
|
|
180 |
|
|
181 |
- ARRAYREF
|
|
182 |
|
|
183 |
An array reference such as `[1, 2, 3]` or `\@foo`.
|
|
184 |
|
|
185 |
- HASHREF
|
|
186 |
|
|
187 |
A hash reference such as `{ a => 1, b => 2 }` or `\%bar`.
|
|
188 |
|
|
189 |
- CODEREF
|
|
190 |
|
|
191 |
A subroutine reference such as `\&foo_sub` or `sub { print "hello" }`.
|
|
192 |
|
|
193 |
- GLOB
|
|
194 |
|
|
195 |
This one is a bit tricky. A glob would be something like `*FOO`, but
|
|
196 |
not `\*FOO`, which is a glob reference. It should be noted that this
|
|
197 |
trick:
|
|
198 |
|
|
199 |
my $fh = do { local *FH; };
|
|
200 |
|
|
201 |
makes `$fh` a glob, not a glob reference. On the other hand, the
|
|
202 |
return value from `Symbol::gensym` is a glob reference. Either can
|
|
203 |
be used as a file or directory handle.
|
|
204 |
|
|
205 |
- GLOBREF
|
|
206 |
|
|
207 |
A glob reference such as `\*FOO`. See the [GLOB](https://metacpan.org/pod/GLOB) entry above
|
|
208 |
for more details.
|
|
209 |
|
|
210 |
- SCALARREF
|
|
211 |
|
|
212 |
A reference to a scalar such as `\$x`.
|
|
213 |
|
|
214 |
- UNDEF
|
|
215 |
|
|
216 |
An undefined value
|
|
217 |
|
|
218 |
- OBJECT
|
|
219 |
|
|
220 |
A blessed reference.
|
|
221 |
|
|
222 |
- BOOLEAN
|
|
223 |
|
|
224 |
This is a special option, and is just a shortcut for `UNDEF | SCALAR`.
|
|
225 |
|
|
226 |
- HANDLE
|
|
227 |
|
|
228 |
This option is also special, and is just a shortcut for `GLOB |
|
|
229 |
GLOBREF`. However, it seems likely that most people interested in
|
|
230 |
either globs or glob references are likely to really be interested in
|
|
231 |
whether the parameter in question could be a valid file or directory
|
|
232 |
handle.
|
|
233 |
|
|
234 |
To specify that a parameter must be of a given type when using named
|
|
235 |
parameters, do this:
|
|
236 |
|
|
237 |
validate(
|
|
238 |
@_, {
|
|
239 |
foo => { type => SCALAR },
|
|
240 |
bar => { type => HASHREF }
|
|
241 |
}
|
|
242 |
);
|
|
243 |
|
|
244 |
If a parameter can be of more than one type, just use the bitwise or
|
|
245 |
(`|`) operator to combine them.
|
|
246 |
|
|
247 |
validate( @_, { foo => { type => GLOB | GLOBREF } );
|
|
248 |
|
|
249 |
For positional parameters, this can be specified as follows:
|
|
250 |
|
|
251 |
validate_pos( @_, { type => SCALAR | ARRAYREF }, { type => CODEREF } );
|
|
252 |
|
|
253 |
## Interface Validation
|
|
254 |
|
|
255 |
To specify that a parameter is expected to have a certain set of
|
|
256 |
methods, we can do the following:
|
|
257 |
|
|
258 |
validate(
|
|
259 |
@_, {
|
|
260 |
foo =>
|
|
261 |
# just has to be able to ->bar
|
|
262 |
{ can => 'bar' }
|
|
263 |
}
|
|
264 |
);
|
|
265 |
|
|
266 |
... or ...
|
|
267 |
|
|
268 |
validate(
|
|
269 |
@_, {
|
|
270 |
foo =>
|
|
271 |
# must be able to ->bar and ->print
|
|
272 |
{ can => [qw( bar print )] }
|
|
273 |
}
|
|
274 |
);
|
|
275 |
|
|
276 |
## Class Validation
|
|
277 |
|
|
278 |
A word of warning. When constructing your external interfaces, it is
|
|
279 |
probably better to specify what methods you expect an object to
|
|
280 |
have rather than what class it should be of (or a child of). This
|
|
281 |
will make your API much more flexible.
|
|
282 |
|
|
283 |
With that said, if you want to validate that an incoming parameter
|
|
284 |
belongs to a class (or child class) or classes, do:
|
|
285 |
|
|
286 |
validate(
|
|
287 |
@_,
|
|
288 |
{ foo => { isa => 'My::Frobnicator' } }
|
|
289 |
);
|
|
290 |
|
|
291 |
... or ...
|
|
292 |
|
|
293 |
validate(
|
|
294 |
@_,
|
|
295 |
# must be both, not either!
|
|
296 |
{ foo => { isa => [qw( My::Frobnicator IO::Handle )] } }
|
|
297 |
);
|
|
298 |
|
|
299 |
## Regex Validation
|
|
300 |
|
|
301 |
If you want to specify that a given parameter must match a specific
|
|
302 |
regular expression, this can be done with "regex" spec key. For
|
|
303 |
example:
|
|
304 |
|
|
305 |
validate(
|
|
306 |
@_,
|
|
307 |
{ foo => { regex => qr/^\d+$/ } }
|
|
308 |
);
|
|
309 |
|
|
310 |
The value of the "regex" key may be either a string or a pre-compiled
|
|
311 |
regex created via `qr`.
|
|
312 |
|
|
313 |
If the value being checked against a regex is undefined, the regex is
|
|
314 |
explicitly checked against the empty string ('') instead, in order to
|
|
315 |
avoid "Use of uninitialized value" warnings.
|
|
316 |
|
|
317 |
The `Regexp::Common` module on CPAN is an excellent source of regular
|
|
318 |
expressions suitable for validating input.
|
|
319 |
|
|
320 |
## Callback Validation
|
|
321 |
|
|
322 |
If none of the above are enough, it is possible to pass in one or more
|
|
323 |
callbacks to validate the parameter. The callback will be given the
|
|
324 |
**value** of the parameter as its first argument. Its second argument
|
|
325 |
will be all the parameters, as a reference to either a hash or array.
|
|
326 |
Callbacks are specified as hash reference. The key is an id for the
|
|
327 |
callback (used in error messages) and the value is a subroutine
|
|
328 |
reference, such as:
|
|
329 |
|
|
330 |
validate(
|
|
331 |
@_, {
|
|
332 |
foo => {
|
|
333 |
callbacks => {
|
|
334 |
'smaller than a breadbox' => sub { shift() < $breadbox },
|
|
335 |
'green or blue' =>
|
|
336 |
sub { $_[0] eq 'green' || $_[0] eq 'blue' }
|
|
337 |
}
|
|
338 |
}
|
|
339 |
);
|
|
340 |
|
|
341 |
validate(
|
|
342 |
@_, {
|
|
343 |
foo => {
|
|
344 |
callbacks => {
|
|
345 |
'bigger than baz' => sub { $_[0] > $_[1]->{baz} }
|
|
346 |
}
|
|
347 |
}
|
|
348 |
}
|
|
349 |
);
|
|
350 |
|
|
351 |
## Untainting
|
|
352 |
|
|
353 |
If you want values untainted, set the "untaint" key in a spec hashref
|
|
354 |
to a true value, like this:
|
|
355 |
|
|
356 |
my %p = validate(
|
|
357 |
@_, {
|
|
358 |
foo => { type => SCALAR, untaint => 1 },
|
|
359 |
bar => { type => ARRAYREF }
|
|
360 |
}
|
|
361 |
);
|
|
362 |
|
|
363 |
This will untaint the "foo" parameter if the parameters are valid.
|
|
364 |
|
|
365 |
Note that untainting is only done if _all parameters_ are valid.
|
|
366 |
Also, only the return values are untainted, not the original values
|
|
367 |
passed into the validation function.
|
|
368 |
|
|
369 |
Asking for untainting of a reference value will not do anything, as
|
|
370 |
`Params::Validate` will only attempt to untaint the reference itself.
|
|
371 |
|
|
372 |
## Mandatory/Optional Revisited
|
|
373 |
|
|
374 |
If you want to specify something such as type or interface, plus the
|
|
375 |
fact that a parameter can be optional, do this:
|
|
376 |
|
|
377 |
validate(
|
|
378 |
@_, {
|
|
379 |
foo => { type => SCALAR },
|
|
380 |
bar => { type => ARRAYREF, optional => 1 }
|
|
381 |
}
|
|
382 |
);
|
|
383 |
|
|
384 |
or this for positional parameters:
|
|
385 |
|
|
386 |
validate_pos(
|
|
387 |
@_,
|
|
388 |
{ type => SCALAR },
|
|
389 |
{ type => ARRAYREF, optional => 1 }
|
|
390 |
);
|
|
391 |
|
|
392 |
By default, parameters are assumed to be mandatory unless specified as
|
|
393 |
optional.
|
|
394 |
|
|
395 |
## Dependencies
|
|
396 |
|
|
397 |
It also possible to specify that a given optional parameter depends on
|
|
398 |
the presence of one or more other optional parameters.
|
|
399 |
|
|
400 |
validate(
|
|
401 |
@_, {
|
|
402 |
cc_number => {
|
|
403 |
type => SCALAR,
|
|
404 |
optional => 1,
|
|
405 |
depends => [ 'cc_expiration', 'cc_holder_name' ],
|
|
406 |
},
|
|
407 |
cc_expiration { type => SCALAR, optional => 1 },
|
|
408 |
cc_holder_name { type => SCALAR, optional => 1 },
|
|
409 |
}
|
|
410 |
);
|
|
411 |
|
|
412 |
In this case, "cc\_number", "cc\_expiration", and "cc\_holder\_name" are
|
|
413 |
all optional. However, if "cc\_number" is provided, then
|
|
414 |
"cc\_expiration" and "cc\_holder\_name" must be provided as well.
|
|
415 |
|
|
416 |
This allows you to group together sets of parameters that all must be
|
|
417 |
provided together.
|
|
418 |
|
|
419 |
The `validate_pos()` version of dependencies is slightly different,
|
|
420 |
in that you can only depend on one other parameter. Also, if for
|
|
421 |
example, the second parameter 2 depends on the fourth parameter, then
|
|
422 |
it implies a dependency on the third parameter as well. This is
|
|
423 |
because if the fourth parameter is required, then the user must also
|
|
424 |
provide a third parameter so that there can be four parameters in
|
|
425 |
total.
|
|
426 |
|
|
427 |
`Params::Validate` will die if you try to depend on a parameter not
|
|
428 |
declared as part of your parameter specification.
|
|
429 |
|
|
430 |
## Specifying defaults
|
|
431 |
|
|
432 |
If the `validate()` or `validate_pos()` functions are called in a list
|
|
433 |
context, they will return a hash or containing the original parameters plus
|
|
434 |
defaults as indicated by the validation spec.
|
|
435 |
|
|
436 |
If the function is not called in a list context, providing a default
|
|
437 |
in the validation spec still indicates that the parameter is optional.
|
|
438 |
|
|
439 |
The hash or array returned from the function will always be a copy of
|
|
440 |
the original parameters, in order to leave `@_` untouched for the
|
|
441 |
calling function.
|
|
442 |
|
|
443 |
Simple examples of defaults would be:
|
|
444 |
|
|
445 |
my %p = validate( @_, { foo => 1, bar => { default => 99 } } );
|
|
446 |
|
|
447 |
my @p = validate_pos( @_, 1, { default => 99 } );
|
|
448 |
|
|
449 |
In scalar context, a hash reference or array reference will be
|
|
450 |
returned, as appropriate.
|
|
451 |
|
|
452 |
# USAGE NOTES
|
|
453 |
|
|
454 |
## Validation failure
|
|
455 |
|
|
456 |
By default, when validation fails `Params::Validate` calls
|
|
457 |
`Carp::confess()`. This can be overridden by setting the `on_fail`
|
|
458 |
option, which is described in the ["GLOBAL" OPTIONS](https://metacpan.org/pod/"GLOBAL" OPTIONS)
|
|
459 |
section.
|
|
460 |
|
|
461 |
## Method calls
|
|
462 |
|
|
463 |
When using this module to validate the parameters passed to a method
|
|
464 |
call, you will probably want to remove the class/object from the
|
|
465 |
parameter list **before** calling `validate()` or `validate_pos()`.
|
|
466 |
If your method expects named parameters, then this is necessary for
|
|
467 |
the `validate()` function to actually work, otherwise `@_` will not
|
|
468 |
be usable as a hash, because it will first have your object (or
|
|
469 |
class) **followed** by a set of keys and values.
|
|
470 |
|
|
471 |
Thus the idiomatic usage of `validate()` in a method call will look
|
|
472 |
something like this:
|
|
473 |
|
|
474 |
sub method {
|
|
475 |
my $self = shift;
|
|
476 |
|
|
477 |
my %params = validate(
|
|
478 |
@_, {
|
|
479 |
foo => 1,
|
|
480 |
bar => { type => ARRAYREF },
|
|
481 |
}
|
|
482 |
);
|
|
483 |
}
|
|
484 |
|
|
485 |
## Speeding Up Validation
|
|
486 |
|
|
487 |
In most cases, the validation spec will remain the same for each call to a
|
|
488 |
subroutine. In that case, you can speed up validation by defining the
|
|
489 |
validation spec just once, rather than on each call to the subroutine:
|
|
490 |
|
|
491 |
my %spec = ( ... );
|
|
492 |
sub foo {
|
|
493 |
my %params = validate( @_, \%spec );
|
|
494 |
}
|
|
495 |
|
|
496 |
You can also use the `state` feature to do this:
|
|
497 |
|
|
498 |
use feature 'state';
|
|
499 |
|
|
500 |
sub foo {
|
|
501 |
state $spec = { ... };
|
|
502 |
my %params = validate( @_, $spec );
|
|
503 |
}
|
|
504 |
|
|
505 |
# "GLOBAL" OPTIONS
|
|
506 |
|
|
507 |
Because the API for the `validate()` and `validate_pos()` functions does not
|
|
508 |
make it possible to specify any options other than the validation spec, it is
|
|
509 |
possible to set some options as pseudo-'globals'. These allow you to specify
|
|
510 |
such things as whether or not the validation of named parameters should be
|
|
511 |
case sensitive, for one example.
|
|
512 |
|
|
513 |
These options are called pseudo-'globals' because these settings are
|
|
514 |
**only applied to calls originating from the package that set the
|
|
515 |
options**.
|
|
516 |
|
|
517 |
In other words, if I am in package `Foo` and I call
|
|
518 |
`validation_options()`, those options are only in effect when I call
|
|
519 |
`validate()` from package `Foo`.
|
|
520 |
|
|
521 |
While this is quite different from how most other modules operate, I
|
|
522 |
feel that this is necessary in able to make it possible for one
|
|
523 |
module/application to use Params::Validate while still using other
|
|
524 |
modules that also use Params::Validate, perhaps with different
|
|
525 |
options set.
|
|
526 |
|
|
527 |
The downside to this is that if you are writing an app with a standard
|
|
528 |
calling style for all functions, and your app has ten modules, **each
|
|
529 |
module must include a call to `validation_options()`**. You could of
|
|
530 |
course write a module that all your modules use which uses various
|
|
531 |
trickery to do this when imported.
|
|
532 |
|
|
533 |
## Options
|
|
534 |
|
|
535 |
- normalize\_keys => $callback
|
|
536 |
|
|
537 |
This option is only relevant when dealing with named parameters.
|
|
538 |
|
|
539 |
This callback will be used to transform the hash keys of both the
|
|
540 |
parameters and the parameter spec when `validate()` or
|
|
541 |
`validate_with()` are called.
|
|
542 |
|
|
543 |
Any alterations made by this callback will be reflected in the
|
|
544 |
parameter hash that is returned by the validation function. For
|
|
545 |
example:
|
|
546 |
|
|
547 |
sub foo {
|
|
548 |
return validate_with(
|
|
549 |
params => \@_,
|
|
550 |
spec => { foo => { type => SCALAR } },
|
|
551 |
normalize_keys =>
|
|
552 |
sub { my $k = shift; $k =~ s/^-//; return uc $k },
|
|
553 |
);
|
|
554 |
|
|
555 |
}
|
|
556 |
|
|
557 |
%p = foo( foo => 20 );
|
|
558 |
|
|
559 |
# $p{FOO} is now 20
|
|
560 |
|
|
561 |
%p = foo( -fOo => 50 );
|
|
562 |
|
|
563 |
# $p{FOO} is now 50
|
|
564 |
|
|
565 |
The callback must return a defined value.
|
|
566 |
|
|
567 |
If a callback is given then the deprecated "ignore\_case" and
|
|
568 |
"strip\_leading" options are ignored.
|
|
569 |
|
|
570 |
- allow\_extra => $boolean
|
|
571 |
|
|
572 |
If true, then the validation routine will allow extra parameters not
|
|
573 |
named in the validation specification. In the case of positional
|
|
574 |
parameters, this allows an unlimited number of maximum parameters
|
|
575 |
(though a minimum may still be set). Defaults to false.
|
|
576 |
|
|
577 |
- on\_fail => $callback
|
|
578 |
|
|
579 |
If given, this callback will be called whenever a validation check
|
|
580 |
fails. It will be called with a single parameter, which will be a
|
|
581 |
string describing the failure. This is useful if you wish to have
|
|
582 |
this module throw exceptions as objects rather than as strings, for
|
|
583 |
example.
|
|
584 |
|
|
585 |
This callback is expected to `die()` internally. If it does not, the
|
|
586 |
validation will proceed onwards, with unpredictable results.
|
|
587 |
|
|
588 |
The default is to simply use the Carp module's `confess()` function.
|
|
589 |
|
|
590 |
- stack\_skip => $number
|
|
591 |
|
|
592 |
This tells Params::Validate how many stack frames to skip when finding
|
|
593 |
a subroutine name to use in error messages. By default, it looks one
|
|
594 |
frame back, at the immediate caller to `validate()` or
|
|
595 |
`validate_pos()`. If this option is set, then the given number of
|
|
596 |
frames are skipped instead.
|
|
597 |
|
|
598 |
- ignore\_case => $boolean
|
|
599 |
|
|
600 |
DEPRECATED
|
|
601 |
|
|
602 |
This is only relevant when dealing with named parameters. If it is
|
|
603 |
true, then the validation code will ignore the case of parameter
|
|
604 |
names. Defaults to false.
|
|
605 |
|
|
606 |
- strip\_leading => $characters
|
|
607 |
|
|
608 |
DEPRECATED
|
|
609 |
|
|
610 |
This too is only relevant when dealing with named parameters. If this
|
|
611 |
is given then any parameters starting with these characters will be
|
|
612 |
considered equivalent to parameters without them entirely. For
|
|
613 |
example, if this is specified as '-', then `-foo` and `foo` would be
|
|
614 |
considered identical.
|
|
615 |
|
|
616 |
# PER-INVOCATION OPTIONS
|
|
617 |
|
|
618 |
The `validate_with()` function can be used to set the options listed
|
|
619 |
above on a per-invocation basis. For example:
|
|
620 |
|
|
621 |
my %p = validate_with(
|
|
622 |
params => \@_,
|
|
623 |
spec => {
|
|
624 |
foo => { type => SCALAR },
|
|
625 |
bar => { default => 10 }
|
|
626 |
},
|
|
627 |
allow_extra => 1,
|
|
628 |
);
|
|
629 |
|
|
630 |
In addition to the options listed above, it is also possible to set
|
|
631 |
the option "called", which should be a string. This string will be
|
|
632 |
used in any error messages caused by a failure to meet the validation
|
|
633 |
spec.
|
|
634 |
|
|
635 |
This subroutine will validate named parameters as a hash if the "spec"
|
|
636 |
parameter is a hash reference. If it is an array reference, the
|
|
637 |
parameters are assumed to be positional.
|
|
638 |
|
|
639 |
my %p = validate_with(
|
|
640 |
params => \@_,
|
|
641 |
spec => {
|
|
642 |
foo => { type => SCALAR },
|
|
643 |
bar => { default => 10 }
|
|
644 |
},
|
|
645 |
allow_extra => 1,
|
|
646 |
called => 'The Quux::Baz class constructor',
|
|
647 |
);
|
|
648 |
|
|
649 |
my @p = validate_with(
|
|
650 |
params => \@_,
|
|
651 |
spec => [
|
|
652 |
{ type => SCALAR },
|
|
653 |
{ default => 10 }
|
|
654 |
],
|
|
655 |
allow_extra => 1,
|
|
656 |
called => 'The Quux::Baz class constructor',
|
|
657 |
);
|
|
658 |
|
|
659 |
# DISABLING VALIDATION
|
|
660 |
|
|
661 |
If the environment variable `PERL_NO_VALIDATION` is set to something
|
|
662 |
true, then validation is turned off. This may be useful if you only
|
|
663 |
want to use this module during development but don't want the speed
|
|
664 |
hit during production.
|
|
665 |
|
|
666 |
The only error that will be caught will be when an odd number of
|
|
667 |
parameters are passed into a function/method that expects a hash.
|
|
668 |
|
|
669 |
If you want to selectively turn validation on and off at runtime, you
|
|
670 |
can directly set the `$Params::Validate::NO_VALIDATION` global
|
|
671 |
variable. It is **strongly** recommended that you **localize** any
|
|
672 |
changes to this variable, because other modules you are using may
|
|
673 |
expect validation to be on when they execute. For example:
|
|
674 |
|
|
675 |
{
|
|
676 |
local $Params::Validate::NO_VALIDATION = 1;
|
|
677 |
|
|
678 |
# no error
|
|
679 |
foo( bar => 2 );
|
|
680 |
}
|
|
681 |
|
|
682 |
# error
|
|
683 |
foo( bar => 2 );
|
|
684 |
|
|
685 |
sub foo {
|
|
686 |
my %p = validate( @_, { foo => 1 } );
|
|
687 |
...;
|
|
688 |
}
|
|
689 |
|
|
690 |
But if you want to shoot yourself in the foot and just turn it off, go
|
|
691 |
ahead!
|
|
692 |
|
|
693 |
# TAINT MODE
|
|
694 |
|
|
695 |
The XS implementation of this module has some problems Under taint mode with
|
|
696 |
version of Perl before 5.14. If validation _fails_, then instead of getting
|
|
697 |
the expected error message you'll get a message like "Insecure dependency in
|
|
698 |
eval\_sv". This can be worked around by either untainting the arguments
|
|
699 |
yourself, using the pure Perl implementation, or upgrading your Perl.
|
|
700 |
|
|
701 |
# LIMITATIONS
|
|
702 |
|
|
703 |
Right now there is no way (short of a callback) to specify that
|
|
704 |
something must be of one of a list of classes, or that it must possess
|
|
705 |
one of a list of methods. If this is desired, it can be added in the
|
|
706 |
future.
|
|
707 |
|
|
708 |
Ideally, there would be only one validation function. If someone
|
|
709 |
figures out how to do this, please let me know.
|
|
710 |
|
|
711 |
# SUPPORT
|
|
712 |
|
|
713 |
Please submit bugs and patches to the CPAN RT system at
|
|
714 |
http://rt.cpan.org/NoAuth/ReportBug.html?Queue=Params%3A%3AValidate or
|
|
715 |
via email at bug-params-validate@rt.cpan.org.
|
|
716 |
|
|
717 |
Support questions can be sent to Dave at autarch@urth.org.
|
|
718 |
|
|
719 |
# DONATIONS
|
|
720 |
|
|
721 |
If you'd like to thank me for the work I've done on this module,
|
|
722 |
please consider making a "donation" to me via PayPal. I spend a lot of
|
|
723 |
free time creating free software, and would appreciate any support
|
|
724 |
you'd care to offer.
|
|
725 |
|
|
726 |
Please note that **I am not suggesting that you must do this** in order
|
|
727 |
for me to continue working on this particular software. I will
|
|
728 |
continue to do so, inasmuch as I have in the past, for as long as it
|
|
729 |
interests me.
|
|
730 |
|
|
731 |
Similarly, a donation made in this way will probably not make me work
|
|
732 |
on this software much more, unless I get so many donations that I can
|
|
733 |
consider working on free software full time, which seems unlikely at
|
|
734 |
best.
|
|
735 |
|
|
736 |
To donate, log into PayPal and send money to autarch@urth.org or use
|
|
737 |
the button on this page:
|
|
738 |
[http://www.urth.org/~autarch/fs-donation.html](http://www.urth.org/~autarch/fs-donation.html)
|
|
739 |
|
|
740 |
# AUTHORS
|
|
741 |
|
|
742 |
- Dave Rolsky <autarch@urth.org>
|
|
743 |
- Ilya Martynov <ilya@martynov.org>
|
|
744 |
|
|
745 |
# CONTRIBUTORS
|
|
746 |
|
|
747 |
- J.R. Mash <jmash.code@gmail.com>
|
|
748 |
- Olivier Mengué <dolmen@cpan.org>
|
|
749 |
|
|
750 |
# COPYRIGHT AND LICENSE
|
|
751 |
|
|
752 |
This software is Copyright (c) 2014 by Dave Rolsky and Ilya Martynov.
|
|
753 |
|
|
754 |
This is free software, licensed under:
|
|
755 |
|
|
756 |
The Artistic License 2.0 (GPL Compatible)
|