PLUGINS

Plugins

Plugins in JCORE are meant to be simple/small self contained units of business logic. Generally this will mean at least 1 service class but could include helper/support classes, plugin specific configurations and other assets.

The plugin structure is set up to allow addition plugins to be added by "drag and drop". The default set up requires that the plugin be "registered" in the API configuration. To do this JCORE uses a modified autoload routine (see CORE/LOAD/AUTOLOAD_PLUGIN.php) that requires plugins to follow a specific name space.

Directory Structure:

[plugin name]/
    CLASS/
        [plugin name].class.php

OpenIDClient/
    CLASS/
        OpenIDClient.class.php - the service class
        OpenIDProviders.class.php - a support class

The full path being something like:
/var/www/JCORE/PLUGINS/OpenIDClient/CLASS/OpenIDClient.class.php

Support classes should be stored under the CLASS directory and other assets may be stored any where in the plugin directory. If these assets are MIME content that are to be "HTTP exposed" directly they should be stored in a separate "asset" directory that can be sym-linked to your HTTP directory space. side notation example here

We'll use a simple auth API for an example. The API requires that we have 3 plugins, an openID client, a connector to OpenLDAP and an OpenID user class.

We define the list of plugins required by the API

$pluginList = array(
    'OpenIDClient',
    'OpenLDAP',
    'OID_User'
);

Then we register the list with the configuration manager

foreach($pluginList AS $key => $pluginName){
    $CONFIG_MANAGER->registerPlugin($pluginName); 
}

The plugin is responsible for managing all of its own assets. It is recommended that any additional support classes etc. should be loaded using require_once at the top of the service class.

ROAD MAP there are plans to to allow the loading of ini files from plugins and packages