Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
Dancer::Plugin::RPC::XUserCContributed Perl DocuDancer::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


	   sub rpc_show_abilities {
	       return {
		   # datastructure

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

   xmlrpc '/endpoint' => \%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

	   o	   on_success


	   o	   on_failure

			   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;

       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:

				   admin.someFunction: rpc_admin_some_function_name
				   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.

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

perl v5.32.1			  2020-12-08	Dancer::Plugin::RPC::XMLRPC(3)


Want to link to this manual page? Use this URL:

home | help