NAME

Dancer::Plugin::RPC::XMLRPC - XMLRPC Plugin for Dancer

SYNOPSIS

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;

DESCRIPTION

This plugin lets one bind an endpoint to a set of modules with the new xmlrpc keyword.

xmlrpc '/endpoint' => \%publisher_arguments;

\%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:

• on_success

  callback_success()

• on_failure

  callback_fail(
      error_code    => <numeric_code>,
      error_message => <error message>
  )

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.

=for xmlrpc xmlrpc-method-name sub-name

This special POD-construct is used for coupling the xmlrpc-methodname to the actual sub-name in the current package.

INTERNAL

xmlrpc_response

Serializes the data passed as an xmlrpc response.

build_dispatcher_from_config

Creates a (partial) dispatch table from data passed from the (YAML)-config file.

build_dispatcher_from_pod

Creates a (partial) dispatch table from data provided in POD.

COPYRIGHT

(c) MMXV - Abe Timmerman <abeltje@cpan.org>