1Params::CallbackRequestU(s3e)r Contributed Perl DocumentaPtairoanms::CallbackRequest(3)
2
6 Params::CallbackRequest - Functional and object-oriented callback
7 architecture
8
10 Functional parameter-triggered callbacks:
11 use strict;
13 use Params::CallbackRequest;
14 # Create a callback function.
16 sub calc_time {
17 my $cb = shift;
18 my $params = $cb->params;
19 my $val = $cb->value;
20 $params->{my_time} = localtime($val || time);
21 }
22 # Set up a callback request object.
24 my $cb_request = Params::CallbackRequest->new(
25 callbacks => [ { cb_key => 'calc_time',
26 pkg_key => 'myCallbacker',
27 cb => \&calc_time } ]
28 );
29 # Request callback execution.
31 my %params = ('myCallbacker|calc_time_cb' => 1);
32 $cb_request->request(\%params);
33 # Demonstrate the result.
35 print "The time is $params{my_time}\n";
36 Or, in a subclass of Params::Callback:
38 package MyApp::Callback;
40 use base qw(Params::Callback);
41 __PACKAGE__->register_subclass( class_key => 'myCallbacker' );
42 # Set up a callback method.
44 sub calc_time : Callback {
45 my $self = shift;
46 my $params = $self->request_params;
47 my $val = $cb->value;
48 $params->{my_time} = localtime($val || time);
49 }
50 And then, in your application:
52 # Load order is important here!
54 use MyApp::Callback;
55 use Params::CallbackRequest;
56 my $cb_request = Params::Callback->new( cb_classes => [qw(myCallbacker)] );
58 my %params = ('myCallbacker|calc_time_cb' => 1);
59 $cb_request->request(\%params);
60 print "The time is $params{my_time}\n";
61
63 Params::CallbackRequest provides functional and object-oriented
64 callbacks to method and function parameters. Callbacks may be either
65 code references provided to the new() constructor, or methods defined
66 in subclasses of Params::Callback. Callbacks are triggered either for
67 every call to the Params::CallbackRequest request() method, or by
68 specially named keys in the parameters to request().
69 The idea behind this module is to provide a sort of plugin architecture
71 for Perl templating systems. Callbacks are triggered by the contents of
72 a request to the Perl templating server, before the templating system
73 itself executes. This approach allows you to carry out logical
74 processing of data submitted from a form, to affect the contents of the
75 request parameters before they're passed to the templating system for
76 processing, and even to redirect or abort the request before the
77 templating system handles it.
78
80 Why would you want to do this? Well, there are a number of reasons.
81 Some I can think of offhand include:
82 Stricter separation of logic from presentation
84 While some Perl templating systems enforce separation of
85 application logic from presentation (e.g., TT, HTML::Template),
86 others do not (e.g., HTML::Mason, Apache::ASP). Even in the former
87 case, application logic is often put into scripts that are executed
88 alongside the presentation templates, and loaded on-demand under
89 mod_perl. By moving the application logic into Perl modules and
90 then directing the templating system to execute that code as
91 callbacks, you obviously benefit from a cleaner separation of
92 application logic and presentation.
93 Widgitization
95 Thanks to their ability to preprocess parameters, callbacks enable
96 developers to develop easier-to-use, more dynamic widgets that can
97 then be used in any and all templating systems. For example, a
98 widget that puts many related fields into a form (such as a date
99 selection widget) can have its fields preprocessed by a callback
100 (for example, to properly combine the fields into a unified date
101 parameter) before the template that responds to the form submission
102 gets the data. See Params::Callback for an example solution for
103 this very problem.
104 Shared Memory
106 If you run your templating system under mod_perl, callbacks are
107 just Perl subroutines in modules loaded at server startup time.
108 Thus the memory they consume is all in the Apache parent process,
109 and shared by the child processes. For code that executes
110 frequently, this can be much less resource-intensive than code in
111 templates, since templates are loaded separately in each Apache
112 child process on demand.
113 Performance
115 Since they're executed before the templating architecture does much
116 processing, callbacks have the opportunity to short-circuit the
117 template processing by doing something else. A good example is
118 redirection. Often the application logic in callbacks does its
119 thing and then redirects the user to a different page. Executing
120 the redirection in a callback eliminates a lot of extraneous
121 processing that would otherwise be executed before the redirection,
122 creating a snappier response for the user.
123 Testing
125 Templating system templates are not easy to test via a testing
126 framework such as Test::Harness. Subroutines in modules, on the
127 other hand, are fully testable. This means that you can write tests
128 in your application test suite to test your callback subroutines.
129 And if those aren't enough reasons, then just consider this: Callbacks
131 are just way cool.
132
134 Params::CallbackRequest supports two different types of callbacks:
135 those triggered by a specially named parameter keys, and those executed
136 for every request.
137 Parameter-Triggered Callbacks
139 Parameter-triggered callbacks are triggered by specially named
140 parameter keys. These keys are constructed as follows: The package name
141 followed by a pipe character ("|"), the callback key with the string
142 "_cb" appended to it, and finally an optional priority number at the
143 end. For example, if you specified a callback with the callback key
144 "save" and the package key "world", a callback field might be specified
145 like this:
146 my $params = { "world|save_cb" => 'Save World' };
148 When the parameters hash $params is passed to Params::CallbackRequest's
150 request() method, the "world|save_cb" parameter would trigger the
151 callback associated with the "save" callback key in the "world"
152 package. If such a callback hasn't been configured, then
153 Params::CallbackRequest will throw a
154 Params::CallbackRequest::Exceptions::InvalidKey exception. Here's how
155 to configure a functional callback when constructing your
156 Params::CallbackRequest object so that that doesn't happen:
157 my $cb_request = Params::CallbackRequest->new
159 ( callbacks => [ { pkg_key => 'world',
160 cb_key => 'save',
161 cb => \&My::World::save } ] );
162 With this configuration, the "world|save_cb" parameter key will trigger
164 the execution of the My::World::save() subroutine during a callback
165 request:
166 # Execute parameter-triggered callback.
168 $cb_request->request($params);
169 Functional Callback Subroutines
171 Functional callbacks use a code reference for parameter-triggered
173 callbacks, and Params::CallbackRequest executes them with a single
174 argument, a Params::Callback object. Thus, a callback subroutine will
175 generally look something like this:
176 sub foo {
178 my $cb = shift;
179 # Do stuff.
180 }
181 The Params::Callback object provides accessors to data relevant to the
183 callback, including the callback key, the package key, and the
184 parameter hash. It also includes an abort() method. See the
185 Params::Callback documentation for all the goodies.
186 Note that Params::CallbackRequest installs an exception handler during
188 the execution of callbacks, so if any of your callback subroutines
189 "die", Params::CallbackRequest will throw an
190 Params::Callback::Exception::Execution exception. If your callback
191 subroutines throw their own exception objects, Params::CallbackRequest
192 will simply rethrow them. If you don't like this configuration, use the
193 "exception_handler" parameter to new() to install your own exception
194 handler.
195 Object-Oriented Callback Methods
197 Object-oriented callback methods, which are supported under Perl 5.6 or
199 later, are defined in subclasses of Params::Callback, and identified by
200 attributes in their declarations. Unlike functional callbacks, callback
201 methods are not called with a Params::Callback object, but with an
202 instance of the callback subclass. These classes inherit all the
203 goodies provided by Params::Callback, so you can essentially use their
204 instances exactly as you would use the Params::Callback object in
205 functional callback subroutines. But because they're subclasses, you
206 can add your own methods and attributes. See Params::Callback for all
207 the gory details on subclassing, along with a few examples. Generally,
208 callback methods will look like this:
209 sub foo : Callback {
211 my $self = shift;
212 # Do stuff.
213 }
214 As with functional callback subroutines, method callbacks are executed
216 with a custom exception handler. Again, see the "exception_handler"
217 parameter to install your own exception handler.
218 Note: Under mod_perl, it's important that you "use" any and all
220 Params::Callback subclasses before you "use Params::CallbackRequest".
221 This is to get around an issue with identifying the names of the
222 callback methods in mod_perl. Read the comments in the Params::Callback
223 source code if you're interested in learning more.
224 The Package Key
226 The use of the package key is a convenience so that a system with many
228 functional callbacks can use callbacks with the same keys but in
229 different packages. The idea is that the package key will uniquely
230 identify the module in which each callback subroutine is found, but it
231 doesn't necessarily have to be so. Use the package key any way you
232 wish, or not at all:
233 my $cb_request = Params::CallbackRequest->new
235 ( callbacks => [ { cb_key => 'save',
236 cb => \&My::World::save } ] );
237 But note that if you don't specify the package key, you'll still need
239 to provide one in the parameter hash passed to request(). By default,
240 that key is "DEFAULT". Such a callback parameter would then look like
241 this:
242 my $params = { "DEFAULT|save_cb" => 'Save World' };
244 If you don't like the "DEFAULT" package name, you can set an
246 alternative default using the "default_pkg_name" parameter to new():
247 my $cb_request = Params::CallbackRequest->new
249 ( callbacks => [ { cb_key => 'save',
250 cb => \&My::World::save } ],
251 default_pkg_name => 'MyPkg' );
252 Then, of course, any callbacks without a specified package key of their
254 own must then use the custom default:
255 my $params = { "MyPkg|save_cb" => 'Save World' };
257 $cb_request->request($params);
258 The Class Key
260 The class key is essentially a synonym for the package key, but applies
262 more directly to object-oriented callbacks. The difference is mainly
263 that it corresponds to an actual class, and that all Params::Callback
264 subclasses are required to have a class key; it's not optional as it is
265 with functional callbacks. The class key may be declared in your
266 Params::Callback subclass like so:
267 package MyApp::CallbackHandler;
269 use base qw(Params::Callback);
270 __PACKAGE__->register_subclass( class_key => 'MyCBHandler' );
271 The class key can also be declared by implementing a "CLASS_KEY"
273 subroutine, like so:
274 package MyApp::CallbackHandler;
276 use base qw(Params::Callback);
277 __PACKAGE__->register_subclass;
278 use constant CLASS_KEY => 'MyCBHandler';
279 If no class key is explicitly defined, Params::Callback will use the
281 subclass name, instead. In any event, the register_callback() method
282 must be called to register the subclass with Params::Callback. See the
283 Params::Callback documentation for complete details.
284 Priority
286 Sometimes one callback is more important than another. For example, you
288 might rely on the execution of one callback to set up variables needed
289 by another. Since you can't rely on the order in which callbacks are
290 executed (the parameters are passed via a hash, and the processing of a
291 hash is, of course, unordered), you need a method of ensuring that the
292 setup callback executes first.
293 In such a case, you can set a higher priority level for the setup
295 callback than for callbacks that depend on it. For functional
296 callbacks, you can do it like this:
297 my $cb_request = Params::CallbackRequest->new
299 ( callbacks => [ { cb_key => 'setup',
300 priority => 3,
301 cb => \&setup },
302 { cb_key => 'save',
303 cb => \&save }
304 ] );
305 For object-oriented callbacks, you can define the priority right in the
307 callback method declaration:
308 sub setup : Callback( priority => 3 ) {
310 my $self = shift;
311 # ...
312 }
313 sub save : Callback {
315 my $self = shift;
316 # ...
317 }
318 In these examples, the "setup" callback has been configured with a
320 priority level of "3". This ensures that it will always execute before
321 the "save" callback, which has the default priority of "5". Obviously,
322 this is true regardless of the order of the fields in the hash:
323 my $params = { "DEFAULT|save_cb" => 'Save World',
325 "DEFAULT|setup_cb" => 1 };
326 In this configuration, the "setup" callback will always execute first
328 because of its higher priority.
329 Although the "save" callback got the default priority of "5", this too
331 can be customized to a different priority level via the
332 "default_priority" parameter to new() for functional callbacks and the
333 "default_priority" to the class declaration for object-oriented
334 callbacks. For example, this functional callback configuration:
335 my $cb_request = Params::CallbackRequest->new
337 ( callbacks => [ { cb_key => 'setup',
338 priority => 3,
339 cb => \&setup },
340 { cb_key => 'save',
341 cb => \&save }
342 ],
343 default_priority => 2 );
344 Or this Params::Callback subclass declaration:
346 package MyApp::CallbackHandler;
348 use base qw(Params::Callback);
349 __PACKAGE__->register_subclass( class_key => 'MyCBHandler',
350 default_priority => 2 );
351 Will cause the "save" callback to always execute before the "setup"
353 callback, since its priority level will default to "2".
354 In addition, the priority level can be overridden via the parameter key
356 itself by appending a priority level to the end of the key name. Hence,
357 this example:
358 my $params = { "DEFAULT|save_cb2" => 'Save World',
360 "DEFAULT|setup_cb" => 1 };
361 Causes the "save" callback to execute before the "setup" callback by
363 overriding the "save" callback's priority to level "2". Of course, any
364 other parameter key that triggers the "save" callback without a
365 priority override will still execute the "save" callback at its
366 configured level.
367 Request Callbacks
369 Request callbacks come in two flavors: those that execute before the
370 parameter-triggered callbacks, and those that execute after the
371 parameter-triggered callbacks. Functional request callbacks may be
372 specified via the "pre_callbacks" and "post_callbacks" parameters to
373 new(), respectively:
374 my $cb_request = Params::CallbackRequest->new
376 ( pre_callbacks => [ \&translate, \&foobarate ],
377 post_callbacks => [ \&escape, \&negate ] );
378 Object-oriented request callbacks may be declared via the "PreCallback"
380 and "PostCallback" method attributes, like so:
381 sub translate : PreCallback { ... }
383 sub foobarate : PreCallback { ... }
384 sub escape : PostCallback { ... }
385 sub negate : PostCallback { ... }
386 In these examples, the translate() and foobarate() subroutines or
388 methods will execute (in that order) before any parameter-triggered
389 callbacks are executed (none will be in these examples, since none are
390 specified).
391 Conversely, the escape() and negate() subroutines or methods will be
393 executed (in that order) after all parameter-triggered callbacks have
394 been executed. And regardless of what parameter-triggered callbacks may
395 be triggered, the request callbacks will always be executed for every
396 request (unless an exception is thrown by an earlier callback).
397 Although they may be used for different purposes, the "pre_callbacks"
399 and "post_callbacks" functional callback code references expect the
400 same argument as parameter-triggered functional callbacks: a
401 Params::Callback object:
402 sub foo {
404 my $cb = shift;
405 # Do your business here.
406 }
407 Similarly, object-oriented request callback methods will be passed an
409 object of the class defined in the class key portion of the callback
410 trigger -- either an object of the class in which the callback is
411 defined, or an object of a subclass:
412 sub foo : PostCallback {
414 my $self = shift;
415 # ...
416 }
417 Of course, the attributes of the Params::Callback or subclass object
419 will be different than in parameter-triggered callbacks. For example,
420 the "priority", "pkg_key", and "cb_key" attributes will naturally be
421 undefined. It will, however, be the same instance of the object passed
422 to all other functional callbacks -- or to all other class callbacks
423 with the same class key -- in a single request.
424 Like the parameter-triggered callbacks, request callbacks run under the
426 nose of a custom exception handler, so if any of them "die"s, an
427 Params::Callback::Exception::Execution exception will be thrown. Use
428 the "exception_handler" parameter to new() if you don't like this.
429
431 Parameters To The new() Constructor
432 Params::CallbackRequest supports a number of its own parameters to the
433 new() constructor (though none of them, sadly, trigger callbacks). The
434 parameters to new() are as follows:
435 "callbacks"
437 Parameter-triggered functional callbacks are configured via the
438 "callbacks" parameter. This parameter is an array reference of hash
439 references, and each hash reference specifies a single callback.
440 The supported keys in the callback specification hashes are:
441 "cb_key"
443 Required. A string that, when found in a properly-formatted
444 parameter hash key, will trigger the execution of the callback.
445 "cb"
447 Required. A reference to the Perl subroutine that will be
448 executed when the "cb_key" has been found in a parameter hash
449 passed to request(). Each code reference should expect a single
450 argument: a Params::Callback object. The same instance of a
451 Params::Callback object will be used for all functional
452 callbacks in a single call to request().
453 "pkg_key"
455 Optional. A key to uniquely identify the package in which the
456 callback subroutine is found. This parameter is useful in
457 systems with many callbacks, where developers may wish to use
458 the same "cb_key" for different subroutines in different
459 packages. The default package key may be set via the
460 "default_pkg_key" parameter to new().
461 "priority"
463 Optional. Indicates the level of priority of a callback. Some
464 callbacks are more important than others, and should be
465 executed before the others. Params::CallbackRequest supports
466 priority levels ranging from "0" (highest priority) to "9"
467 (lowest priority). The default priority for functional
468 callbacks may be set via the "default_priority" parameter.
469 "pre_callbacks"
471 This parameter accepts an array reference of code references that
472 should be executed for every call to request() before any
473 parameter-triggered callbacks. They will be executed in the order
474 in which they're listed in the array reference. Each code reference
475 should expect a Params::Callback object as its sole argument. The
476 same instance of a Params::Callback object will be used for all
477 functional callbacks in a single call to request(). Use pre-
478 parameter-triggered request callbacks when you want to do something
479 with the parameters submitted for every call to request(), such as
480 convert character sets.
481 "post_callbacks"
483 This parameter accepts an array reference of code references that
484 should be executed for every call to request() after all parameter-
485 triggered callbacks have been called. They will be executed in the
486 order in which they're listed in the array reference. Each code
487 reference should expect a Params::Callback object as its sole
488 argument. The same instance of a Params::Callback object will be
489 used for all functional callbacks in a single call to request().
490 Use post-parameter-triggered request callbacks when you want to do
491 something with the parameters submitted for every call to
492 request(), such as encode or escape their values for presentation.
493 "cb_classes"
495 An array reference listing the class keys of all of the
496 Params::Callback subclasses containing callback methods that you
497 want included in your Params::CallbackRequest object.
498 Alternatively, the "cb_classes" parameter may simply be the word
499 "ALL", in which case all Params::Callback subclasses will have
500 their callback methods registered with your Params::CallbackRequest
501 object. See the Params::Callback documentation for details on
502 creating callback classes and methods.
503 Note: In a mod_perl environment, be sure to "use
505 Params::CallbackRequest" only after you've "use"d all of the
506 Params::Callback subclasses you need or else you won't be able to
507 use their callback methods.
508 "default_priority"
510 The priority level at which functional callbacks will be executed.
511 Does not apply to object-oriented callbacks. This value will be
512 used in each hash reference passed via the "callbacks" parameter to
513 new() that lacks a "priority" key. You may specify a default
514 priority level within the range of "0" (highest priority) to "9"
515 (lowest priority). If not specified, it defaults to "5".
516 "default_pkg_key"
518 The default package key for functional callbacks. Does not apply to
519 object-oriented callbacks. This value that will be used in each
520 hash reference passed via the "callbacks" parameter to new() that
521 lacks a "pkg_key" key. It can be any string that evaluates to a
522 true value, and defaults to "DEFAULT" if not specified.
523 "ignore_nulls"
525 By default, Params::CallbackRequest will execute all callbacks
526 triggered by parameter hash keys. However, in many situations it
527 may be desirable to skip any callbacks that have no value for the
528 callback field. One can do this by simply checking "$cbh->value" in
529 the callback, but if you need to disable the execution of all
530 parameter-triggered callbacks when the callback parameter value is
531 undefined or the null string (''), pass the "ignore_null" parameter
532 with a true value. It is set to a false value by default.
533 "leave_notes"
535 By default, Params::CallbackRequest will clear out the contents of
536 the hash accessed via the notes() method just before returning from
537 a call to request(). There may be some circumstances when it's
538 desirable to allow the notes hash to persist beyond the duration of
539 a a call to request(). For example, a templating architecture may
540 wish to keep the notes around for the duration of the execution of
541 a template request. In such cases, pass a true value to the
542 "leave_notes" parameter, and use the clear_notes() method to
543 manually clear out the notes hash at the appropriate point.
544 "exception_handler"
546 Params::CallbackRequest installs a custom exception handler during
547 the execution of callbacks. This custom exception handler will
548 simply rethrow any exception objects it comes across, but will
549 throw a Params::Callback::Exception::Execution exception object if
550 it is passed only a string value (such as is passed by "die
551 "fool!"").
552 But if you find that you're throwing your own exceptions in your
554 callbacks, and want to handle them differently, pass the
555 "exception_handler" parameter a code reference to do what you need.
556 Instance Methods
558 Params::CallbackRequest of course has several instance methods. I cover
559 the most important, first.
560 request
562 $cb_request->request(\%params);
564 # If you're in a mod_perl environment, pass in an Apache request object
566 # to be passed to the Callback classes.
567 $cb_request->request(\%params, apache_req => $r);
568 # Or pass in argument to be passed to callback class constructors.
570 $cb_request->request(\%params, @args);
571 Executes the callbacks specified when the Params::CallbackRequest
573 object was created. It takes a single required argument, a hash
574 reference of parameters. Any subsequent arguments are passed to the
575 constructor for each callback class for which callbacks will be
576 executed. By default, the only extra parameter supported by the
577 Params::Callback base class is an Apache request object, which can be
578 passed via the "apache_req" parameter. Returns the
579 Params::CallbackRequest object on success, or the code passed to
580 Params::Callback's abort() method if callback execution was aborted.
581 A single call to request() is referred to as a "callback request"
583 (naturally!). First, all pre-request callbacks are executed. Then, any
584 parameter-triggered callbacks triggered by the keys in the parameter
585 hash reference passed as the sole argument are executed. And finally,
586 all post-request callbacks are executed. request() returns the
587 Params::CallbackRequest object on successful completion of the request.
588 Any callback that calls abort() on its Params::Callback object will
590 prevent any other callbacks scheduled by the request to run subsequent
591 to its execution from being executed (including post-request
592 callbacks). Furthermore, any callback that "die"s or throws an
593 exception will of course also prevent any subsequent callbacks from
594 executing, and in addition must also be caught by the caller or the
595 whole process will terminate:
596 eval { $cb_request->request(\%params) };
598 if (my $err = $@) {
599 # Handle exception.
600 }
601 notes
603 $cb_request->notes($key => $value);
605 my $val = $cb_request->notes($key);
606 my $notes = $cb_request->notes;
607 The notes() method provides a place to store application data, giving
609 developers a way to share data among multiple callbacks over the course
610 of a call to request(). Any data stored here persists for the duration
611 of the request unless the "leave_notes" parameter to new() has been
612 passed a true value. In such cases, use clear_notes() to manually clear
613 the notes.
614 Conceptually, notes() contains a hash of key-value pairs. "notes($key,
616 $value)" stores a new entry in this hash. notes($key) returns a
617 previously stored value. notes() without any arguments returns a
618 reference to the entire hash of key-value pairs.
619 notes() is similar to the mod_perl method "$r->pnotes()". The main
621 differences are that this notes() can be used in a non-mod_perl
622 environment, and that its lifetime is tied to the lifetime of the call
623 to request() unless the "leave_notes" parameter is true.
624 For the sake of convenience, a shortcut to notes() is provide to
626 callback code via the notes() method in Params::Callback.
627 clear_notes
629 $cb_request->clear_notes;
631 Use this method to clear out the notes hash. Most useful when the
633 "leave_notes" parameter to new() has been set to at true value and you
634 need to manage the clearing of notes yourself. This method is
635 specifically designed for a templating environment, where it may be
636 advantageous for the templating architecture to allow the notes to
637 persist beyond the duration of a call to request(), e.g., to keep them
638 for the duration of a call to the templating architecture itself. See
639 MasonX::Interp::WithCallbacks for an example of this strategy.
640 Accessor Methods
642 The properties "default_priority" and "default_pkg_key" have standard
643 read-only accessor methods of the same name. For example:
644 my $cb_request = Params::CallbackRequest->new;
646 my $default_priority = $cb_request->default_priority;
647 my $default_pkg_key = $cb_request->default_pkg_key;
648
650 Garth Webb implemented the original callbacks in Bricolage, based on an
651 idea he borrowed from Paul Lindner's work with Apache::ASP. My thanks
652 to them both for planting this great idea! This implementation is
653 however completely independent of previous implementations.
654
656 Params::Callback objects get passed as the sole argument to all
657 functional callbacks, and offer access to data relevant to the
658 callback. Params::Callback also defines the object-oriented callback
659 interface, making its documentation a must-read for anyone who wishes
660 to create callback classes and methods.
661 MasonX::Interp::WithCallbacks uses this module to provide a callback
663 architecture for HTML::Mason.
664
666 This module is stored in an open GitHub repository
667 <http://github.com/theory/params-callbackrequest/>. Feel free to fork
668 and contribute!
669 Please file bug reports via GitHub Issues
671 <http://github.com/theory/params-callbackrequest/issues/> or by sending
672 mail to bug-params-callbackrequest@rt.cpan.org <mailto:bug-params-
673 callbackrequest@rt.cpan.org>.
674
676 David E. Wheeler <david@justatheory.com>
677
679 Copyright 2003-2011 David E. Wheeler. Some Rights Reserved.
680 This library is free software; you can redistribute it and/or modify it
682 under the same terms as Perl itself.
683perl v5.36.0 2023-01-20 Params::CallbackRequest(3)