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 the
333       "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 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
398       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
403         sub foo {
404             my $cb = shift;
405             # Do your business here.
406         }
407
408       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
413         sub foo : PostCallback {
414             my $self = shift;
415             # ...
416         }
417
418       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
425       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

INTERFACE

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
436       "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
442           "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
446           "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
454           "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
462           "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
470       "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
482       "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
494       "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
504           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
509       "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
517       "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
524       "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
534       "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
545       "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
553           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
557   Instance Methods
558       Params::CallbackRequest of course has several instance methods. I cover
559       the most important, first.
560
561       request
562
563         $cb_request->request(\%params);
564
565         # 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
569         # Or pass in argument to be passed to callback class constructors.
570         $cb_request->request(\%params, @args);
571
572       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
582       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
589       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
597         eval { $cb_request->request(\%params) };
598         if (my $err = $@) {
599             # Handle exception.
600         }
601
602       notes
603
604         $cb_request->notes($key => $value);
605         my $val = $cb_request->notes($key);
606         my $notes = $cb_request->notes;
607
608       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
615       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
620       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
625       For the sake of convenience, a shortcut to notes() is provide to
626       callback code via the notes() method in Params::Callback.
627
628       clear_notes
629
630         $cb_request->clear_notes;
631
632       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
641   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
645         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

ACKNOWLEDGMENTS

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

SEE ALSO

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

SUPPORT

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

AUTHOR

676       David E. Wheeler <david@justatheory.com>
677
679       Copyright 2003-2011 David E. Wheeler. Some Rights Reserved.
680
681       This library is free software; you can redistribute it and/or modify it
682       under the same terms as Perl itself.
683
684
685
686perl v5.36.0                      2023-01-20        Params::CallbackRequest(3)
Impressum