Core framework

The core framework handles database access, security, settings, and most of the raw functionality needed by the CASH platform. It's important to point out that the core framework is licensed with an LGPL license, while the rest of our code building on top of it is AGPL.

##Basic CASHRequest->CASHResponse flow Two main classes, CASHRequest and CASHResponse drive most of the process, following a modified factory/worker pattern. The CASHRequest is instantiated with a cash_request_type, cash_action, and parameters, either in an array or specified in GET/POST parameters. (We specify security for each action, so not all requests will be allowed for all methods.)

This looks something like:

<?php
$request = new CASHRequest(
	array(
		'cash_request_type' => 'system',
		'cash_action' => 'notarealcall',
		'parameter_1' => 'one',
		'parameter_2' => 2
	)
);
$response = $request->response;
$response_data = $response['payload'];
?>

(The order of parameters does not matter.)

Once the CASHRequest has a valid type and action it passes the parameters on to what we're calling a Plant class. Currently the valid Plant types are system, asset, people, commerce, calendar, and element. These correspond to the SystemPlant, AssetPlant, PeoplePlant, etc.

The Plant has access to a central CASHData object and takes care of any and all DB interaction in a uniform way. Should any third-party services or highly-specific functionality be needed the Plants have access to Seed objects, which provide a consistent interface to specific libraries and/or APIs. (Think "CommercePlant" and "PaypalSeed" for a simple example.) This architecture lets us abstract calls away from specific services and provide a consistent interface. It's easy to create new service seeds and use them with existing Plant actions — and we're looking to make that even easier.

When a Plant gets a return it passes it to a CASHResponse object, which adds a status code, contextual message, and places all data returned in a payload variable. So the CASHResponse is always returned in a consistent format making it easy to work with, and consistent even when run locally or via API.

##Plants Plants provide specific functionality based on a high-level grouping. It's no accident that they fall under the same categories as the admin app — the idea is to unify the language that platform users and developers both use.

Plants start with a routing table connection cash_actions to internal functions. They use Reflection to test which parameters are required, what default values for optional parameters should be, and how to order the passed parameters.

Requests are processed using a Plant's processRequest() method, which ultimately returns data to a CASHRequest to be formatted as a CASHResponse.

##Seeds Seeds provide specific functionality in the CASH Music platform. Generally they wrap APIs and libraries, allowing needed parameters (like API keys or settings) to be stored in the database and be used with the Seed. Seeds are generally instantiated with a user_id and connection_id to provide both settings and security.

Seeds are stored with a type that matches a JSON definition file in the /settings folder, allowing them to take a recognizable shape for the library or API they're working with. This definition file is also responsible for telling the admin how to store the settings for a given connection, and to filter connections by scope so we don't display Paypal connections on an asset storage form.

##Documentation We auto-generate documentation for all core requests available so the latest docs are always accessible to developers in their repo. They also live online at:

http://cashmusic.github.com/platform/