Params::Callback(3) User Contributed Perl Documentation Params::Callback(3)NAMEParams::Callback - Parameter callback base class
SYNOPSIS
Functional callback interface:
sub my_callback {
# Sole argument is a Params::Callback object.
my $cb = shift;
my $params = $cb->params;
my $value = $cb->value;
# Do stuff with above data.
}
Object-oriented callback interface:
package MyApp::Callback;
use base qw(Params::Callback);
use constant CLASS_KEY => 'MyHandler';
use strict;
sub my_callback : Callback {
my $self = shift;
my $params = $self->params;
my $value = $self->value;
# Do stuff with above data.
}
DESCRIPTIONParams::Callback provides the interface for callbacks to access
parameter hashes Params::CallbackRequest object, and callback metadata,
as well as for executing common request actions, such as aborting a
callback execution request. There are two ways to use Params::Callback:
via functional-style callback subroutines and via object-oriented
callback methods.
For functional callbacks, a Params::Callback object is constructed by
Params::CallbackRequest for each call to its "request()" method, and
passed as the sole argument for every execution of a callback function.
See Params::CallbackRequest for details on how to create a
Params::CallbackRequest object to execute your callback code.
In the object-oriented callback interface, Params::Callback is the
parent class from which all callback classes inherit. Callback methods
are declared in such subclasses via "Callback", "PreCallback", and
"PostCallback" attributes to each method declaration. Methods and
subroutines declared without one of these callback attributes are not
callback methods, but normal methods or subroutines of the subclass.
Read subclassing for details on subclassing Params::Callback.
INTERFACEParams::Callback provides the parameter hash accessors and utility
methods that will help manage a callback request (where a "callback
request" is considered a single call to the "request()" method on a
Params::CallbackRequest object). Functional callbacks always get a
Params::Callback object passed as their first argument; the same
Params::Callback object will be used for all callbacks in a single
request. For object-oriented callback methods, the first argument will
of course always be an object of the class corresponding to the class
key used in the callback key (or, for request callback methods, an
instance of the class for which the request callback method was
loaded), and the same object will be reused for all subsequent
callbacks to the same class in a single request.
Accessor Methods
All of the Params::Callback accessor methods are read-only. Feel free
to add other attributes in your Params::Callback subclasses if you're
using the object-oriented callback interface.
cb_request
my $cb_request = $cb->cb_request;
Returns a reference to the Params::CallbackRequest object that executed
the callback.
params
my $params = $cb->params;
Returns a reference to the request parameters hash. Any changes you
make to this hash will propagate beyond the lifetime of the request.
apache_req
my $r = $cb->apache_req;
Returns the Apache request object for the current request, provided
you've passed one to "Params::CallbackRequest->request". This will be
most useful in a mod_perl environment, of course. Use
Apache:FakeRequest in tests to emmulate the behavior of an Apache
request object.
requester
my $r = $cb->requester;
Returns the object that executed the callback by calling "request()" on
a Params::CallbackRequest object. Only available if the "requester"
parameter is passed to "Params::CallbackRequest->request". This can be
useful for callbacks to get access to the object that executed the
callbacks.
priority
my $priority = $cb->priority;
Returns the priority level at which the callback was executed. Possible
values range from "0" to "9", and may be set by a default priority
setting, by the callback configuration or method declaration, or by the
parameter callback trigger key. See Params::CallbackRequest for
details.
cb_key
my $cb_key = $cb->cb_key;
Returns the callback key that triggered the execution of the callback.
For example, this callback-triggering parameter hash:
my $params = { "DEFAULT|save_cb" => 'Save' };
Will cause the "cb_key()" method in the relevant callback to return
"save".
pkg_key
my $pkg_key = $cb->pkg_key;
Returns the package key used in the callback trigger parameter key. For
example, this callback-triggering parameter hash:
my $params = { "MyCBs|save_cb" => 'Save' };
Will cause the "pkg_key()" method in the relevant callback to return
"MyCBs".
class_key
my $class_key = $cb->class_key;
An alias for "pkg_key", only perhaps a bit more appealing for use in
object-oriented callback methods.
trigger_key
my $trigger_key = $cb->trigger_key;
Returns the complete parameter key that triggered the callback. For
example, if the parameter key that triggered the callback looks like
this:
my $params = { "MyCBs|save_cb6" => 'Save' };
Then the value returned by "trigger_key()" method will be
"MyCBs|save_cb6".
Note: Most browsers will submit "image" input fields with two
arguments, one with ".x" appended to its name, and the other with ".y"
appended to its name. Because Params::CallbackRequest is designed to be
used with Web form fields populating a parameter hash, it will ignore
these fields and either use the field that's named without the ".x" or
".y", or create a field with that name and give it a value of "1". The
reasoning behind this approach is that the names of the callback-
triggering fields should be the same as the names that appear in the
HTML form fields. If you want the actual x and y image click
coordinates, access them directly from the request parameters:
my $params = $cb->params;
my $trigger_key = $cb->trigger_key;
my $x = $params->{"$trigger_key.x"};
my $y = $params->{"$trigger_key.y"};
value
my $value = $cb->value;
Returns the value of the parameter that triggered the callback. This
value can be anything that can be stored in a hash value -- that is,
any scalar value. Thus, in this example:
my $params = { "DEFAULT|save_cb" => 'Save',
"DEFAULT|open_cb" => [qw(one two)] };
"value()" will return the string "Save" in the save callback, but the
array reference "['one', 'two']" in the open callback.
Although you may often be able to retrieve the value directly from the
hash reference returned by "params()", if multiple callback keys point
to the same subroutine or if the parameter that triggered the callback
overrode the priority, you may not be able to determine which value was
submitted for a particular callback execution. So Params::Callback
kindly provides the value for you. The exception to this rule is values
submitted under keys named for HTML "image" input fields. See the note
about this under the documentation for the "trigger_key()" method.
redirected
$cb->redirect($url) unless $cb->redirected;
If the request has been redirected, this method returns the redirection
URL. Otherwise, it returns false. This method is useful for conditions
in which one callback has called "$cb->redirect" with the optional
$wait argument set to a true value, thus allowing subsequent callbacks
to continue to execute. If any of those subsequent callbacks want to
call "$cb->redirect" themselves, they can check the value of
"$cb->redirected" to make sure it hasn't been done already.
Other Methods
Params::Callback offers has a few other publicly accessible methods.
notes
$cb->notes($key => $value);
my $val = $cb->notes($key);
my $notes = $cb->notes;
Shortcut for "$cb->cb_request->notes". It provides a place to store
application data, giving developers a way to share data among multiple
callbacks. See "notes()" for more information.
redirect
$cb->redirect($url);
$cb->redirect($url, $wait);
$cb->redirect($url, $wait, $status);
This method can be used to redirect a request in a mod_perl
environment, provided that an Apache request object has been passed to
"Params::CallbackRequest->new". Outide of a mod_perl environment or
without an Apache request object, "redirect()" will still set the
proper value for the the "redirected()" method to return, and will
still abort the callback request.
Given a URL, this method generates a proper HTTP redirect for that URL.
By default, the status code used is "302", but this can be overridden
via the $status argument. If the optional $wait argument is true, any
callbacks scheduled to be executed after the call to "redirect" will
continue to be executed. In that case, "$cb->abort" will not be called;
rather, Params::CallbackRequest will finish executing all remaining
callbacks and then return the abort status. If the $wait argument is
unspecified or false, then the request will be immediately terminated
without executing subsequent callbacks or. This approach relies on the
execution of "$cb->abort".
Since "$cb->redirect" calls "$cb->abort", it will be trapped by an
"eval {}" block. If you are using an "eval {}" block in your code to
trap exceptions, you need to make sure to rethrow these exceptions,
like this:
eval {
...
};
die $@ if $cb->aborted;
# handle other exceptions
abort
$cb->abort($status);
Aborts the current request without executing any more callbacks. The
$status argument specifies a request status code to be returned to by
"Params::CallbackRequest->request()".
"abort()" is implemented by throwing a
Params::Callback::Exception::Abort object and can thus be caught by
"eval{}". The "aborted()" method is a shortcut for determining whether
an exception was generated by "abort()".
aborted
die $err if $cb->aborted;
die $err if $cb->aborted($err);
Returns true or "undef" to indicate whether the specified $err was
generated by "abort()". If no $err argument is passed, "aborted()"
examines $@, instead.
In this code, we catch and process fatal errors while letting "abort()"
exceptions pass through:
eval { code_that_may_die_or_abort() };
if (my $err = $@) {
die $err if $cb->aborted($err);
# handle fatal errors...
}
$@ can lose its value quickly, so if you're planning to call
"$cb->aborted" more than a few lines after the "eval", you should save
$@ to a temporary variable and explicitly pass it to "aborted()" as in
the above example.
SUBCLASSING
Under Perl 5.6.0 and later, Params::Callback offers an object-oriented
callback interface. The object-oriented approach is to subclass
Params::Callback, add the callback methods you need, and specify a
class key that uniquely identifies your subclass across all
Params::Callback subclasses in your application. The key is to use Perl
method attributes to identify methods as callback methods, so that
Params::Callback can find them and execute them when the time comes.
Here's an example:
package MyApp::CallbackHandler;
use base qw(Params::Callback);
use strict;
__PACKAGE__->register_subclass( class_key => 'MyHandler' );
sub build_utc_date : Callback( priority => 2 ) {
my $self = shift;
my $params = $self->params;
$params->{date} = sprintf "%04d-%02d-%02dT%02d:%02d:%02d",
delete @{$params}{qw(year month day hour minute second)};
}
This parameter-triggered callback can then be executed via a parameter
hash such as this:
my $params = { "MyHandler|build_utc_date_cb" => 1 };
Think of the part of the name preceding the pipe (the package key) as
the class name, and the part of the name after the pipe (the callback
key) as the method to call (plus '_cb'). If multiple parameters use the
"MyHandler" class key in a single request, then a single
MyApp::CallbackHandler object instance will be used to execute each of
those callback methods for that request.
To configure your Params::CallbackRequest object to use this callback,
use its "cb_classes" constructor parameter:
my $cb_request = Params::CallbackRequest->new
( cb_classes => [qw(MyHandler)] );
$cb_request->request($params);
Now, there are a few of things to note in the above callback class
example. The first is the call to "__PACKAGE__->register_subclass".
This step is required in all callback subclasses in order that
Params::Callback will know about them, and thus they can be loaded into
an instance of a Params::CallbackRequest object via its "cb_classes"
constructor parameter.
Second, a callback class key must be declared for the class. This can
be done either by implementing the "CLASS_KEY()" class method or
constant in your subclass, or by passing the "class_key" parameter to
"__PACKAGE__->register_subclass", which will then create the
"CLASS_KEY()" method for you. If no callback key is declared, then
Params::Callback will throw an exception when you try to load your
subclass' callback methods into a Params::CallbackRequest object.
One other, optional parameter, "default_priority", may also be passed
to "register_subclass()". The value of this parameter (an integer
between 0 and 9) will be used to create a "DEFAULT_PRIORITY()" class
method in the subclass. You can also explicitly implement the
"DEFAULT_PRIORITY()" class method or constant in the subclass, if you'd
rather. All parameter-triggered callback methods in that class will
have their priorities set to the value returned by
"DEFAULT_PRIORITY()", unless they override it via their "Callback"
attributes.
And finally, notice the "Callback" attribute on the "build_utc_date"
method declaration in the example above. This attribute is what
identifies "build_utc_date" as a parameter-triggered callback. Without
the "Callback" attribute, any subroutine declaration in your subclass
will just be a subroutine or a method; it won't be a callback, and it
will never be executed by Params::CallbackRequest. One parameter,
"priority", can be passed via the "Callback" attribute. In the above
example, we pass "priority => 2", which sets the priority for the
callback. Without the "priority" parameter, the callback's priority
will be set to the value returned by the "DEFAULT_PRIORITY()" class
method. Of course, the priority can still be overridden by adding it to
the callback trigger key. For example, here we force the callback
priority for the execution of the "build_utc_date" callback method for
this one field to be the highest priority, "0":
my $params = { "MyHandler|build_utc_date_cb0" => 1 };
Other parameters to the "Callback" attribute may be added in future
versions of Params::Callback.
Request callbacks can also be implemented as callback methods using the
"PreCallback" and "PostCallback" attributes, which currently support no
parameters.
Subclassing Examples
At this point, you may be wondering what advantage the object-oriented
callback interface offer over functional callbacks. There are a number
of advantages. First, it allows you to make use of callbacks provided
by other users without having to reinvent the wheel for yourself. Say
someone has implemented the above class with its exceptionally complex
"build_utc_date()" callback method. You need to have the same
functionality, only with fractions of a second added to the date format
so that you can insert them into your database without an error. (This
is admittedly a contrived example, but you get the idea.) To make it
happen, you merely have to subclass the above class and override the
"build_utc_date()" method to do what you need:
package MyApp::Callback::Subclass;
use base qw(MyApp::CallbackHandler);
use strict;
__PACKAGE__->register_subclass;
# Implement CLASS_KEY ourselves.
use constant CLASS_KEY => 'SubHandler';
sub build_utc_date : Callback( priority => 1 ) {
my $self = shift;
$self->SUPER::build_utc_date;
my $params = $self->params;
$params->{date} .= '.000000';
}
This callback can then be triggered by a parameter hash such as this:
my $params = { "SubHandler|build_utc_date_cb" => 1 };
Note that we've used the "SubHandler" class key. If we used the
"MyHandler" class key, then the "build_utc_date()" method would be
called on an instance of the MyApp::CallbackHandler class, instead.
Request Callback Methods
I'll admit that the case for request callback methods is a bit more
tenuous. Granted, a given application may have 100s or even 1000s of
parameter-triggered callbacks, but only one or two request callbacks,
if any. But the advantage of request callback methods is that they
encourage code sharing, in that Params::Callback creates a kind of
plug-in architecture Perl templating architectures.
For example, say someone has kindly created a Params::Callback
subclass, Params::Callback::Unicodify, with the request callback method
"unicodify()", which translates character sets, allowing you to always
store data in the database in Unicode. That's all well and good, as far
as it goes, but let's say that you want to make sure that your Unicode
strings are actually encoded using the Perl "\x{..}" notation. Again,
just subclass:
package Params::Callback::Unicodify::PerlEncode;
use base qw(Params::Callback::Unicodify);
use strict;
__PACKAGE__->register_subclass( class_key => 'PerlEncode' );
sub unicodify : PreCallback {
my $self = shift;
$self->SUPER::unicodify;
my $params = $self->params;
encode_unicode($params); # Hand waving.
}
Now you can just tell Params::CallbackRequest to use your subclassed
callback handler:
my $cb_request = Params::CallbackRequest->new
( cb_classes => [qw(PerlEncode)] );
Yeah, okay, you could just create a second pre-callback request
callback to encode the Unicode characters using the Perl "\x{..}"
notation. But you get the idea. Better examples welcome.
Overriding the Constructor
Another advantage to using callback classes is that you can override
the Params::Callback "new()" constructor. Since every callback for a
single class will be executed on the same instance object in a single
request, you can set up object properties in the constructor that
subsequent callback methods in the same request can then access.
For example, say you had a series of pages that all do different things
to manage objects in your application. Each of those pages might have a
number of parameters in common to assist in constructing an object:
my $params = { class => "MyApp::Spring",
obj_id => 10,
# ...
};
Then the remaining parameters created for each of these pages have
different key/value pairs for doing different things with the object,
perhaps with numerous parameter-triggered callbacks. Here's where
subclassing comes in handy: you can override the constructor to
construct the object when the callback object is constructed, so that
each of your callback methods doesn't have to:
package MyApp::Callback;
use base qw(Params::Callback);
use strict;
__PACKAGE__->register_subclass( class_key => 'MyCBHandler' );
sub new {
my $class = shift;
my $self = $class->SUPER::new(@_);
my $params = $self->params;
$self->object($params->{class}->lookup( id => $params->{obj_id} ));
}
sub object {
my $self = shift;
if (@_) {
$self->{object} = shift;
}
return $self->{object};
}
sub save : Callback {
my $self = shift;
$self->object->save;
}
SUBCLASSING INTERFACE
Much of the interface for subclassing Params::Callback is evident in
the above examples. Here is a reference to the complete callback
subclassing API.
Callback Class Declaration
Callback classes always subclass Params::Callback, so of course they
must always declare such. In addition, callback classes must always
call "__PACKAGE__->register_subclass" so that Params::Callback is aware
of them and can tell Params::CallbackRequest about them.
Second, callback classes must have a class key. The class key can be
created either by implementing a "CLASS_KEY()" class method or constant
that returns the class key, or by passing the "class_key" parameter to
"register_subclass()" method. If no "class_key" parameter is passed to
"register_subclass()" and no "CLASS_KEY()" method exists,
"register_subclass()" will create the "CLASS_KEY()" class method to
return the actual class name. So here are a few example callback class
declarations:
package MyApp::Callback;
use base qw(Params::Callback);
__PACKAGE__->register_subclass( class_key => 'MyCBHandler' );
In this declaration "register_subclass()" will create a "CLASS_KEY()"
class method returning "MyCBHandler" in the MyApp::CallbackHandler
class.
package MyApp::AnotherCallback;
use base qw(MyApp::Callback);
__PACKAGE__->register_subclass;
use constant CLASS_KEY => 'AnotherCallback';
In this declaration, we've created an explicit "CLASS_KEY()" class
method (using the handy "use constant" syntax, so that
"register_subclass()" doesn't have to.
package MyApp::Callback::Foo;
use base qw(Params::Callback);
__PACKAGE__->register_subclass;
And in this callback class declaration, we've specified neither a
"class_key" parameter to "register_subclass()", nor created a
"CLASS_KEY()" class method. This causes "register_subclass()" to create
the "CLASS_KEY()" class method returning the name of the class itself,
i.e., "MyApp::FooHandler". Thus any parameter-triggered callbacks in
this class can be triggered by using the class name in the trigger key:
my $params = { "MyApp::Callback::Foo|take_action_cb" => 1 };
A second, optional parameter, "default_priority", may also be passed to
"register_subclass()" in order to set a default priority for all of the
methods in the class (and for all the methods in subclasses that don't
declare their own "default_priority"s):
package MyApp::Callback;
use base qw(Params::Callback);
__PACKAGE__->register_subclass( class_key => 'MyCB',
default_priority => 7 );
As with the "class_key" parameter, the "default_priority" parameter
creates a class method, "DEFAULT_PRIORITY()". If you'd rather, you can
create this class method yourself; just be sure that its value is a
valid priority -- that is, an integer between "0" and "9":
package MyApp::Callback;
use base qw(Params::Callback);
use constant DEFAULT_PRIORITY => 7;
__PACKAGE__->register_subclass( class_key => 'MyCB' );
Any callback class that does not specify a default priority via the
"default_priority" or by implementing a <DEFAULT_PRIORITY()> class
method will simply inherit the priority returned by
"Params::Callback->DEFAULT_PRIORITY", which is "5".
Note: In a mod_perl environment, it's important that you "use" any and
all Params::Callback subclasses before you "use
Params::CallbackRequest". This is to get around an issue with
identifying the names of the callback methods in mod_perl. Read the
comments in the source code if you're interested in learning more.
Method Attributes
These method attributes are required to create callback methods in
Params::Callback subclasses.
Callback
sub take_action : Callback {
my $self = shift;
# Do stuff.
}
This attribute identifies a parameter-triggered callback method. The
callback key is the same as the method name ("take_action" in this
example). The priority for the callback may be set via an optional
"priority" parameter to the "Callback" attribute, like so:
sub take_action : Callback( priority => 5 ) {
my $self = shift;
# Do stuff.
}
Otherwise, the priority will be that returned by
"$self->DEFAULT_PRIORITY".
Note: The priority set via the "priority" parameter to the "Callback"
attribute is not inherited by any subclasses that override the callback
method. This may change in the future.
PreCallback
sub early_action : PreCallback {
my $self = shift;
# Do stuff.
}
This attribute identifies a method as a request callback that gets
executed for every request before any parameter-triggered callbacks are
executed . No parameters to "PreCallback" are currently supported.
PostCallback
sub late_action : PostCallback {
my $self = shift;
# Do stuff.
}
This attribute identifies a method as a request callback that gets
executed for every request after any parameter-triggered callbacks are
executed . No parameters to "PostCallback" are currently supported.
TODO
ยท Allow methods that override parent methods to inherit the parent
method's priority?
SEE ALSO
Params::CallbackRequest constructs Params::Callback objects and
executes the appropriate callback functions and/or methods. It's worth
a read.
SUPPORT
This module is stored in an open repository at the following address:
https://svn.kineticode.com/Params-CallbackRequest/trunk/
<https://svn.kineticode.com/Params-CallbackRequest/trunk/>
Patches against Params::CallbackRequest are welcome. Please send bug
reports to <bug-params-callbackrequest@rt.cpan.org>.
AUTHOR
David Wheeler <david@kineticode.com>
COPYRIGHT AND LICENSE
Copyright 2003-2008 David Wheeler. Some Rights Reserved.
This library is free software; you can redistribute it and/or modify it
under the same terms as Perl itself.
perl v5.14.1 2011-07-20 Params::Callback(3)
