|
1
|
---------------------------------------------------
|
|
2
|
Some notes for developers working on the rules code
|
|
3
|
---------------------------------------------------
|
|
4
|
|
|
5
|
Terminology & Overview
|
|
6
|
-----------------------
|
|
7
|
* Rules plugins extend the "rules language". Thus conditions and actions are
|
|
8
|
implemented with a plugin, but also loops or ORs are plugins. Each plugin is
|
|
9
|
declared to be used in the condition or the action part - specified by the
|
|
10
|
interface.
|
|
11
|
* The action and condition plugin are a so called "AbstractPlugin" which means
|
|
12
|
they have to be implemented by modules to be actually usable. In fact the
|
|
13
|
callbacks provided by the action or condition implementation are
|
|
14
|
incorporated in the plugin object using faces. That way an action or
|
|
15
|
condition element behaves exactly like any other plugin instance.
|
|
16
|
* Any rule element is an instance of a RulesPlugin.
|
|
17
|
* A rules configuration consists of multiple rule elements while one is the
|
|
18
|
root element, which may be a 'rule' but also any other plugin.
|
|
19
|
* Each rules configuration may be persistently saved to the db using the
|
|
20
|
entity CRUD API. Using the API on contained rule elements is working too and
|
|
21
|
results in the whole configuration being updated.
|
|
22
|
* Rules provides per plugin UI components, what makes the UI parts re-usable
|
|
23
|
outside of the rule admin module too. In fact the rules admin module is
|
|
24
|
pretty small, as it just relies on the provided UI of the components.
|
|
25
|
* The UI is incorporated using the faces object extension mechanism, see
|
|
26
|
rules_rules_plugin_info() for an overview of the used UI extenders.
|
