Section: Coordinator plugins
^ Developping plugins | jAuth drivers » |
− Table of content
Adding coordinator (jelix core class) plugins allows you to customize different steps of the processing of any action.
You can execute some code, at process start, before action execution, after action execution (but before display), at process end.
Note: Coordinator plugins are commonly named coord plugin in Jelix.
Activate a coord plugin ¶
You need to modify entry point configuration file. It could be
var/config/index/config.ini.php
if it is for index.php.
- add its repository e.g the parent directory of your plugin.
- Add the plugin name to
[coordplugins]
sections and set it ot "1" or to the configuration file name if needed.
Example: your plugin is located in foo folder of <application name>/plugins/coord/
.
Your config file should look like:
[coordplugins]
foo = foo.plugin.ini.php
foo.plugin.ini.php
is a dedicated config file. Its content and structure
depends only on the plugin. Having a plugin configuration file is not required.
In that case, you should assign 1 to your plugin name:
[coordplugins]
foo = 1
The value "1"
means also that the configuration of the plugin can be inside
the configuration file of the entry point. It should be into a [coordplugin_XXX]
section (where XXX is the name of the plugin, like [coordplugin_foo]
).
- *Important**: If you are using several coordinator plugins, the order of the plugins declaration in the config file matters. Hence the first declared plugin has precedence on the others. It means that if this first plugin returns an action, the other ones will not be executed. So you need to choose carefully the order of the plugins declaration according to the priority you wish for every plugin. For example if you consider that the bar plugin cannot be executed as long as the foo plugin does not return any action, then you should declare them this way:
[coordplugins]
foo = foo.plugin.ini.php
bar = 1
Plugin configuration ¶
A plugin may need some configuration parameters
In order to configure a plugin, you might have declared a specific configuration
file (see above). It is an ini file, located in app/system/
. Its content
will be passed as an array parameter to your plugin constructor (result of the parse_ini_file
function).
If this is only a section [coordplugin_XXX]
or [XXX]
, its content
will be passed as an array parameter to your plugin constructor.
If there are both a [coordplugin_XXX]
(or [XXX]
) section and a specific configuration file,
only the content of the configuration file is used, unless to indicate a parameter
XXX.mergeconfig
into the section [coordplugins]
, having 1
or on
as value. In this case the content of [coordplugin_XXX]
(or [XXX]
) and the content
of the configuration file are merged (the content of [coordplugin_XXX]
or [XXX]
has priority over the configuration file).
Plugin parameters ¶
As said before, your plugin might need some options or parameters. Some of one can be set within controllers. Indeed, your plugin might do different treatments for each controller actions.
As an example, jAuth plugin checks if an action needs authentication or not. Each controller will set a parameter for each action indicating wether authentication is needed.
There is a member of the controller to serve this purpose: pluginParams
. It is
an associative array. Its keys are method names (actions names) and its values
are arrays setting all plugins parameters. The key *
covers all methods or
actions.
Code Example:
public $pluginParams = array(
'*'=>array('auth.required'=>false)
);
Result: the plugin parameter auth.required
is set to false
for all methods.
See the documentation of the plugin to know which parameters you can use.
Plugin development ¶
Concretely a plugin must implement jICoordPlugin
interface.
And so declare the following methods:
public function __construct($config);
public function beforeAction($params);
public function beforeOutput();
public function afterProcess ();
Class constructor receive its plugin configuration.
beforeAction
method received plugin parameters set by controllers. It can
return null
if all is ok, or an object jSelectorAct
(action selector) if
another action must be executed (sort of redirection).
beforeOutput
will be called after action execution.
afterProcess
method will be called at the end of coordinator processing,
thus just before display.
The class must be located in a plugins repository:
plugins/
application folder or a plugins/
module folder
are possible candidates. See page on plugins.
For an example plugin:
- plugin folder will be
plugins/coord/example/
. - its file will be
plugins/coord/example/example.coord.php
- its class will be
CexampleCoordPlugin
and will implementjICoordPlugin
interface.
Replacing a plugin ¶
It may be useful for one plugin to impersonate another.
The first way is to indicate the name of the original plugin in a parameter
whose name ends by .name
. Example:
[coordplugins]
cas=cas.coord.ini.php
cas.name=auth
Here, we activate the cas
plugin, but it will be known under the name auth
.
Of course, the replaced plugin must not be activated.
The second way, that can be used since Jelix 1.7.9, it to indicate an alternate
class, in a parameter whose name ends by .class
.
[coordplugins]
auth=auth.coord.ini.php
auth.class=casCoordPlugin
Here, the plugin named "auth" use the class of the plugin cas
.
So the class should be the name of an other plugin, or any other class that is autoloaded.