++ed by:
AERO

1 PAUSE user

Tobias Oetiker
and 1 contributors

NAME

CallBackery::RpcService - RPC services for CallBackery

SYNOPSIS

This module gets instantiated by CallBackery and provides backend functionality.

DESCRIPTION

This module provides the following methods

allow_rpc_access(method)

is this method accessible?

logRpcCall

set CALLBACKERY_RPC_LOG for extensive logging messages. Note that all values with keys matching /password|_pass/ do get replaced with 'xxx' in the output.

logRpcReturn

set CALLBACKERY_RPC_LOG for extensive logging messages. Note that all values with keys matching /password|_pass/ do get replaced with 'xxx' in the output.

ping()

check if the server is happy with our authentication state

getSessionCookie()

Return a timeestamped session cookie. For use in the X-Session-Cookie header or as a xsc field in form submissions. Note that session cookies for form submissions are only valid for 2 seconds. So you have to get a fresh one from the server before submitting your form.

getConfig()

get some gloabal configuration information into the interface

login(user,password)

Check login and provide the user specific interface configuration as a response.

logout

Kill the session.

instantiatePlugin

get an instance for the given plugin

processPluginData(plugin,args)

handle form sumissions

validateField(plugin,args)

validate the content of the given field for the given plugin

getPluginData(plugin,args);

return the current value for the given field

getUserConfig

returns user specific configuration information

getPluginConfig(plugin,args)

returns a plugin configuration removing all the 'back end' keys and non ARRAY or HASH references in the process.

runEventActions(event[,args])

Call the eventAction handlers of all configured plugins. Currently the following events are known.

   changeConfig

setPreDestroyAction(key,callback);

This can be used to have tasks completed at the end of a webtransaction since the controller gets instantiated per transaction. An example application would be backing up the configuration changes only once even if more than one configChange event has occured.

handleUpload

Process incoming upload request. This is getting called via a route and NOT in the usual way, hence we have to render our own response!

handleDownload

Process incoming download request. The handler expects two parameters: name for the plugin instance and formData for the data of the webform.

The handler getting the request must return a hash with the following elements:

filename

name of the download when saved

type

mime-type of the download

asset

a Mojo::Asset. eg Mojo::Asset::File-new(path => '/etc/passwd')>.

BUGS

The idea was to implement preDestoryActions via a DESTROY method, but it seems that the datastructures in the controller are not letting it DESTORY itself as the handle goes out of scope. For now I am using the finish event on tx ... not pretty.

COPYRIGHT

Copyright (c) 2013 by OETIKER+PARTNER AG. All rights reserved.

LICENSE

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

AUTHOR

Tobias Oetiker <tobi@oetiker.ch>

HISTORY

 2013-01-01 to Initial