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
333 the "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
393 be executed (in that order) after all parameter-triggered callbacks
394 have been executed. And regardless of what parameter-triggered
395 callbacks may be triggered, the request callbacks will always be
396 executed for every request (unless an exception is thrown by an earlier
397 callback).
398 Although they may be used for different purposes, the "pre_callbacks"
400 and "post_callbacks" functional callback code references expect the
401 same argument as parameter-triggered functional callbacks: a
402 Params::Callback object:
403 sub foo {
405 my $cb = shift;
406 # Do your business here.
407 }
408 Similarly, object-oriented request callback methods will be passed an
410 object of the class defined in the class key portion of the callback
411 trigger -- either an object of the class in which the callback is
412 defined, or an object of a subclass:
413 sub foo : PostCallback {
415 my $self = shift;
416 # ...
417 }
418 Of course, the attributes of the Params::Callback or subclass object
420 will be different than in parameter-triggered callbacks. For example,
421 the "priority", "pkg_key", and "cb_key" attributes will naturally be
422 undefined. It will, however, be the same instance of the object passed
423 to all other functional callbacks -- or to all other class callbacks
424 with the same class key -- in a single request.
425 Like the parameter-triggered callbacks, request callbacks run under the
427 nose of a custom exception handler, so if any of them "die"s, an
428 Params::Callback::Exception::Execution exception will be thrown. Use
429 the "exception_handler" parameter to "new()" if you don't like this.
430
432 Parameters To The "new()" Constructor
433 Params::CallbackRequest supports a number of its own parameters to the
434 "new()" constructor (though none of them, sadly, trigger callbacks).
435 The parameters to "new()" are as follows:
436 "callbacks"
438 Parameter-triggered functional callbacks are configured via the
439 "callbacks" parameter. This parameter is an array reference of hash
440 references, and each hash reference specifies a single callback.
441 The supported keys in the callback specification hashes are:
442 "cb_key"
444 Required. A string that, when found in a properly-formatted
445 parameter hash key, will trigger the execution of the callback.
446 "cb"
448 Required. A reference to the Perl subroutine that will be
449 executed when the "cb_key" has been found in a parameter hash
450 passed to "request()". Each code reference should expect a
451 single argument: a Params::Callback object. The same instance
452 of a Params::Callback object will be used for all functional
453 callbacks in a single call to "request()".
454 "pkg_key"
456 Optional. A key to uniquely identify the package in which the
457 callback subroutine is found. This parameter is useful in
458 systems with many callbacks, where developers may wish to use
459 the same "cb_key" for different subroutines in different
460 packages. The default package key may be set via the
461 "default_pkg_key" parameter to "new()".
462 "priority"
464 Optional. Indicates the level of priority of a callback. Some
465 callbacks are more important than others, and should be
466 executed before the others. Params::CallbackRequest supports
467 priority levels ranging from "0" (highest priority) to "9"
468 (lowest priority). The default priority for functional
469 callbacks may be set via the "default_priority" parameter.
470 "pre_callbacks"
472 This parameter accepts an array reference of code references that
473 should be executed for every call to "request()" before any
474 parameter-triggered callbacks. They will be executed in the order
475 in which they're listed in the array reference. Each code reference
476 should expect a Params::Callback object as its sole argument. The
477 same instance of a Params::Callback object will be used for all
478 functional callbacks in a single call to "request()". Use pre-
479 parameter-triggered request callbacks when you want to do something
480 with the parameters submitted for every call to "request()", such
481 as convert character sets.
482 "post_callbacks"
484 This parameter accepts an array reference of code references that
485 should be executed for every call to "request()" after all
486 parameter-triggered callbacks have been called. They will be
487 executed in the order in which they're listed in the array
488 reference. Each code reference should expect a Params::Callback
489 object as its sole argument. The same instance of a
490 Params::Callback object will be used for all functional callbacks
491 in a single call to "request()". Use post-parameter-triggered
492 request callbacks when you want to do something with the parameters
493 submitted for every call to "request()", such as encode or escape
494 their values for presentation.
495 "cb_classes"
497 An array reference listing the class keys of all of the
498 Params::Callback subclasses containing callback methods that you
499 want included in your Params::CallbackRequest object.
500 Alternatively, the "cb_classes" parameter may simply be the word
501 "ALL", in which case all Params::Callback subclasses will have
502 their callback methods registered with your Params::CallbackRequest
503 object. See the Params::Callback documentation for details on
504 creating callback classes and methods.
505 Note: In a mod_perl environment, be sure to "use
507 Params::CallbackRequest" only after you've "use"d all of the
508 Params::Callback subclasses you need or else you won't be able to
509 use their callback methods.
510 "default_priority"
512 The priority level at which functional callbacks will be executed.
513 Does not apply to object-oriented callbacks. This value will be
514 used in each hash reference passed via the "callbacks" parameter to
515 "new()" that lacks a "priority" key. You may specify a default
516 priority level within the range of "0" (highest priority) to "9"
517 (lowest priority). If not specified, it defaults to "5".
518 "default_pkg_key"
520 The default package key for functional callbacks. Does not apply to
521 object-oriented callbacks. This value that will be used in each
522 hash reference passed via the "callbacks" parameter to "new()" that
523 lacks a "pkg_key" key. It can be any string that evaluates to a
524 true value, and defaults to "DEFAULT" if not specified.
525 "ignore_nulls"
527 By default, Params::CallbackRequest will execute all callbacks
528 triggered by parameter hash keys. However, in many situations it
529 may be desirable to skip any callbacks that have no value for the
530 callback field. One can do this by simply checking "$cbh->value" in
531 the callback, but if you need to disable the execution of all
532 parameter-triggered callbacks when the callback parameter value is
533 undefined or the null string (''), pass the "ignore_null" parameter
534 with a true value. It is set to a false value by default.
535 "leave_notes"
537 By default, Params::CallbackRequest will clear out the contents of
538 the hash accessed via the "notes()" method just before returning
539 from a call to "request()". There may be some circumstances when
540 it's desirable to allow the notes hash to persist beyond the
541 duration of a a call to "request()". For example, a templating
542 architecture may wish to keep the notes around for the duration of
543 the execution of a template request. In such cases, pass a true
544 value to the "leave_notes" parameter, and use the "clear_notes()"
545 method to manually clear out the notes hash at the appropriate
546 point.
547 "exception_handler"
549 Params::CallbackRequest installs a custom exception handler during
550 the execution of callbacks. This custom exception handler will
551 simply rethrow any exception objects it comes across, but will
552 throw a Params::Callback::Exception::Execution exception object if
553 it is passed only a string value (such as is passed by "die
554 "fool!"").
555 But if you find that you're throwing your own exceptions in your
557 callbacks, and want to handle them differently, pass the
558 "exception_handler" parameter a code reference to do what you need.
559 Instance Methods
561 Params::CallbackRequest of course has several instance methods. I cover
562 the most important, first.
563 request
565 $cb_request->request(\%params);
567 # If you're in a mod_perl environment, pass in an Apache request object
569 # to be passed to the Callback classes.
570 $cb_request->request(\%params, apache_req => $r);
571 # Or pass in argument to be passed to callback class constructors.
573 $cb_request->request(\%params, @args);
574 Executes the callbacks specified when the Params::CallbackRequest
576 object was created. It takes a single required argument, a hash
577 reference of parameters. Any subsequent arguments are passed to the
578 constructor for each callback class for which callbacks will be
579 executed. By default, the only extra parameter supported by the
580 Params::Callback base class is an Apache request object, which can be
581 passed via the "apache_req" parameter. Returns the
582 Params::CallbackRequest object on success, or the code passed to
583 Params::Callback's "abort()" method if callback execution was aborted.
584 A single call to "request()" is referred to as a "callback request"
586 (naturally!). First, all pre-request callbacks are executed. Then, any
587 parameter-triggered callbacks triggered by the keys in the parameter
588 hash reference passed as the sole argument are executed. And finally,
589 all post-request callbacks are executed. "request()" returns the
590 Params::CallbackRequest object on successful completion of the request.
591 Any callback that calls "abort()" on its Params::Callback object will
593 prevent any other callbacks scheduled by the request to run subsequent
594 to its execution from being executed (including post-request
595 callbacks). Furthermore, any callback that "die"s or throws an
596 exception will of course also prevent any subsequent callbacks from
597 executing, and in addition must also be caught by the caller or the
598 whole process will terminate:
599 eval { $cb_request->request(\%params) };
601 if (my $err = $@) {
602 # Handle exception.
603 }
604 notes
606 $cb_request->notes($key => $value);
608 my $val = $cb_request->notes($key);
609 my $notes = $cb_request->notes;
610 The "notes()" method provides a place to store application data, giving
612 developers a way to share data among multiple callbacks over the course
613 of a call to "request()". Any data stored here persists for the
614 duration of the request unless the "leave_notes" parameter to "new()"
615 has been passed a true value. In such cases, use "clear_notes()" to
616 manually clear the notes.
617 Conceptually, "notes()" contains a hash of key-value pairs.
619 "notes($key, $value)" stores a new entry in this hash. "notes($key)"
620 returns a previously stored value. "notes()" without any arguments
621 returns a reference to the entire hash of key-value pairs.
622 "notes()" is similar to the mod_perl method "$r->pnotes()". The main
624 differences are that this "notes()" can be used in a non-mod_perl
625 environment, and that its lifetime is tied to the lifetime of the call
626 to "request()" unless the "leave_notes" parameter is true.
627 For the sake of convenience, a shortcut to "notes()" is provide to
629 callback code via the "notes()" method in Params::Callback.
630 clear_notes
632 $cb_request->clear_notes;
634 Use this method to clear out the notes hash. Most useful when the
636 "leave_notes" parameter to "new()" has been set to at true value and
637 you need to manage the clearing of notes yourself. This method is
638 specifically designed for a templating environment, where it may be
639 advantageous for the templating architecture to allow the notes to
640 persist beyond the duration of a call to "request()", e.g., to keep
641 them for the duration of a call to the templating architecture itself.
642 See MasonX::Interp::WithCallbacks for an example of this strategy.
643 Accessor Methods
645 The properties "default_priority" and "default_pkg_key" have standard
646 read-only accessor methods of the same name. For example:
647 my $cb_request = Params::CallbackRequest->new;
649 my $default_priority = $cb_request->default_priority;
650 my $default_pkg_key = $cb_request->default_pkg_key;
651
653 Garth Webb implemented the original callbacks in Bricolage, based on an
654 idea he borrowed from Paul Lindner's work with Apache::ASP. My thanks
655 to them both for planting this great idea! This implementation is
656 however completely independent of previous implementations.
657
659 Params::Callback objects get passed as the sole argument to all
660 functional callbacks, and offer access to data relevant to the
661 callback. Params::Callback also defines the object-oriented callback
662 interface, making its documentation a must-read for anyone who wishes
663 to create callback classes and methods.
664 MasonX::Interp::WithCallbacks uses this module to provide a callback
666 architecture for HTML::Mason.
667
669 This module is stored in an open GitHub repository
670 <http://github.com/theory/params-callbackrequest/>. Feel free to fork
671 and contribute!
672 Please file bug reports via GitHub Issues
674 <http://github.com/theory/params-callbackrequest/issues/> or by sending
675 mail to bug-params-callbackrequest@rt.cpan.org <mailto:bug-params-
676 callbackrequest@rt.cpan.org>.
677
679 David E. Wheeler <david@justatheory.com>
680
682 Copyright 2003-2011 David E. Wheeler. Some Rights Reserved.
683 This library is free software; you can redistribute it and/or modify it
685 under the same terms as Perl itself.
686perl v5.30.1 2020-01-30 Params::CallbackRequest(3)