1Params::CallbackRequestU(s3e)r Contributed Perl DocumentaPtairoanms::CallbackRequest(3)
2
3
4

NAME

6       Params::CallbackRequest - Functional and object-oriented callback
7       architecture
8

SYNOPSIS

10       Functional parameter-triggered callbacks:
11
12         use strict;
13         use Params::CallbackRequest;
14
15         # 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
23         # 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
30         # Request callback execution.
31         my %params = ('myCallbacker|calc_time_cb' => 1);
32         $cb_request->request(\%params);
33
34         # Demonstrate the result.
35         print "The time is $params{my_time}\n";
36
37       Or, in a subclass of Params::Callback:
38
39         package MyApp::Callback;
40         use base qw(Params::Callback);
41         __PACKAGE__->register_subclass( class_key => 'myCallbacker' );
42
43         # 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
51       And then, in your application:
52
53         # Load order is important here!
54         use MyApp::Callback;
55         use Params::CallbackRequest;
56
57         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

DESCRIPTION

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
70       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

JUSTIFICATION

80       Why would you want to do this? Well, there are a number of reasons.
81       Some I can think of offhand include:
82
83       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
94       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
105       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
114       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
124       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
130       And if those aren't enough reasons, then just consider this: Callbacks
131       are just way cool.
132

USAGE

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
138   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
147         my $params = { "world|save_cb" => 'Save World' };
148
149       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
158         my $cb_request = Params::CallbackRequest->new
159           ( callbacks => [ { pkg_key => 'world',
160                              cb_key  => 'save',
161                              cb      => \&My::World::save } ] );
162
163       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
167         # Execute parameter-triggered callback.
168         $cb_request->request($params);
169
170       Functional Callback Subroutines
171
172       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
177         sub foo {
178             my $cb = shift;
179             # Do stuff.
180         }
181
182       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
187       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
196       Object-Oriented Callback Methods
197
198       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
210         sub foo : Callback {
211             my $self = shift;
212             # Do stuff.
213         }
214
215       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
219       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
225       The Package Key
226
227       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
234         my $cb_request = Params::CallbackRequest->new
235           ( callbacks => [ { cb_key  => 'save',
236                              cb      => \&My::World::save } ] );
237
238       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
243         my $params = { "DEFAULT|save_cb" => 'Save World' };
244
245       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
248         my $cb_request = Params::CallbackRequest->new
249           ( callbacks        => [ { cb_key  => 'save',
250                                     cb      => \&My::World::save } ],
251             default_pkg_name => 'MyPkg' );
252
253       Then, of course, any callbacks without a specified package key of their
254       own must then use the custom default:
255
256         my $params = { "MyPkg|save_cb" => 'Save World' };
257         $cb_request->request($params);
258
259       The Class Key
260
261       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
268         package MyApp::CallbackHandler;
269         use base qw(Params::Callback);
270         __PACKAGE__->register_subclass( class_key => 'MyCBHandler' );
271
272       The class key can also be declared by implementing a "CLASS_KEY"
273       subroutine, like so:
274
275         package MyApp::CallbackHandler;
276         use base qw(Params::Callback);
277         __PACKAGE__->register_subclass;
278         use constant CLASS_KEY => 'MyCBHandler';
279
280       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
285       Priority
286
287       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
294       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
298         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
306       For object-oriented callbacks, you can define the priority right in the
307       callback method declaration:
308
309         sub setup : Callback( priority => 3 ) {
310             my $self = shift;
311             # ...
312         }
313
314         sub save : Callback {
315             my $self = shift;
316             # ...
317         }
318
319       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
324         my $params = { "DEFAULT|save_cb"  => 'Save World',
325                        "DEFAULT|setup_cb" => 1 };
326
327       In this configuration, the "setup" callback will always execute first
328       because of its higher priority.
329
330       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
336         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
345       Or this Params::Callback subclass declaration:
346
347         package MyApp::CallbackHandler;
348         use base qw(Params::Callback);
349         __PACKAGE__->register_subclass( class_key        => 'MyCBHandler',
350                                         default_priority => 2 );
351
352       Will cause the "save" callback to always execute before the "setup"
353       callback, since its priority level will default to "2".
354
355       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
359         my $params = { "DEFAULT|save_cb2" => 'Save World',
360                        "DEFAULT|setup_cb" => 1 };
361
362       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
368   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
375         my $cb_request = Params::CallbackRequest->new
376           ( pre_callbacks  => [ \&translate, \&foobarate ],
377             post_callbacks => [ \&escape, \&negate ] );
378
379       Object-oriented request callbacks may be declared via the "PreCallback"
380       and "PostCallback" method attributes, like so:
381
382         sub translate : PreCallback { ... }
383         sub foobarate : PreCallback { ... }
384         sub escape : PostCallback { ... }
385         sub negate : PostCallback { ... }
386
387       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
392       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
399       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
404         sub foo {
405             my $cb = shift;
406             # Do your business here.
407         }
408
409       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
414         sub foo : PostCallback {
415             my $self = shift;
416             # ...
417         }
418
419       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
426       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

INTERFACE

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
437       "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
443           "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
447           "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
455           "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
463           "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
471       "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
483       "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
496       "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
506           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
511       "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
519       "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
526       "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
536       "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
548       "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
556           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
560   Instance Methods
561       Params::CallbackRequest of course has several instance methods. I cover
562       the most important, first.
563
564       request
565
566         $cb_request->request(\%params);
567
568         # 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
572         # Or pass in argument to be passed to callback class constructors.
573         $cb_request->request(\%params, @args);
574
575       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
585       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
592       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
600         eval { $cb_request->request(\%params) };
601         if (my $err = $@) {
602             # Handle exception.
603         }
604
605       notes
606
607         $cb_request->notes($key => $value);
608         my $val = $cb_request->notes($key);
609         my $notes = $cb_request->notes;
610
611       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
618       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
623       "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
628       For the sake of convenience, a shortcut to "notes()" is provide to
629       callback code via the "notes()" method in Params::Callback.
630
631       clear_notes
632
633         $cb_request->clear_notes;
634
635       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
644   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
648         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

ACKNOWLEDGMENTS

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

SEE ALSO

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
665       MasonX::Interp::WithCallbacks uses this module to provide a callback
666       architecture for HTML::Mason.
667

SUPPORT

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
673       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

AUTHOR

679       David E. Wheeler <david@justatheory.com>
680
682       Copyright 2003-2011 David E. Wheeler. Some Rights Reserved.
683
684       This library is free software; you can redistribute it and/or modify it
685       under the same terms as Perl itself.
686
687
688
689perl v5.30.0                      2019-07-26        Params::CallbackRequest(3)
Impressum