|
|
| |
Dancer::Plugin::RPC::XMLRPC(3) |
User Contributed Perl Documentation |
Dancer::Plugin::RPC::XMLRPC(3) |
Dancer::Plugin::RPC::XMLRPC - XMLRPC Plugin for Dancer
In the Controler-bit:
use Dancer::Plugin::RPC::XMLRPC;
xmlrpc '/endpoint' => {
publish => 'pod',
arguments => ['MyProject::Admin']
};
and in the Model-bit (MyProject::Admin):
package MyProject::Admin;
=for xmlrpc rpc.abilities rpc_show_abilities
=cut
sub rpc_show_abilities {
return {
# datastructure
};
}
1;
This plugin lets one bind an endpoint to a set of modules with the new
xmlrpc keyword.
"\%publisher_arguments"
- callback => $coderef [optional]
- The callback will be called just before the actual rpc-code is called from
the dispatch table. The arguments are positional: (full_request,
method_name).
my Dancer::RPCPlugin::CallbackResult $continue = $callback
? $callback->(request(), $method_name, @method_args)
: callback_success();
The callback should return a Dancer::RPCPlugin::CallbackResult
instance:
- code_wrapper => $coderef [optional]
- The codewrapper will be called with these positional arguments:
- 1. $call_coderef
- 2. $package (where $call_coderef is)
- 3. $method_name
- 4. @arguments
The default code_wrapper-sub is:
sub {
my $code = shift;
my $pkg = shift;
$code->(@_);
};
- publisher => <config | pod | \&code_ref>
- The publiser key determines the way one connects the rpc-method name with
the actual code.
- publisher => 'config'
- This way of publishing requires you to create a dispatch-table in the
app's config YAML:
plugins:
"RPC::XMLRPC":
'/endpoint':
'MyProject::Admin':
admin.someFunction: rpc_admin_some_function_name
'MyProject::User':
user.otherFunction: rpc_user_other_function_name
The Config-publisher doesn't use the
"arguments" value of the
%publisher_arguments hash.
- publisher => 'pod'
- This way of publishing enables one to use a special POD directive
"=for xmlrpc" to connect the rpc-method
name to the actual code. The directive must be in the same file as where
the code resides.
=for xmlrpc admin.someFunction rpc_admin_some_function_name
The POD-publisher needs the
"arguments" value to be an arrayref
with package names in it.
- publisher => \&code_ref
- This way of publishing requires you to write your own way of building the
dispatch-table. The code_ref you supply, gets the
"arguments" value of the
%publisher_arguments hash.
A dispatch-table looks like:
return {
'admin.someFuncion' => dispatch_item(
package => 'MyProject::Admin',
code => MyProject::Admin->can('rpc_admin_some_function_name'),
),
'user.otherFunction' => dispatch_item(
package => 'MyProject::User',
code => MyProject::User->can('rpc_user_other_function_name'),
),
}
- arguments => <anything>
- The value of this key depends on the publisher-method chosen.
This special POD-construct is used for coupling the xmlrpc-methodname to the
actual sub-name in the current package.
Serializes the data passed as an xmlrpc response.
Creates a (partial) dispatch table from data passed from the (YAML)-config file.
Creates a (partial) dispatch table from data provided in POD.
(c) MMXV - Abe Timmerman <abeltje@cpan.org>
Visit the GSP FreeBSD Man Page Interface. Output converted with ManDoc. |