You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
26 lines
1.6 KiB
26 lines
1.6 KiB
--------------------------------------------------- |
|
Some notes for developers working on the rules code |
|
--------------------------------------------------- |
|
|
|
Terminology & Overview |
|
----------------------- |
|
* Rules plugins extend the "rules language". Thus conditions and actions are |
|
implemented with a plugin, but also loops or ORs are plugins. Each plugin is |
|
declared to be used in the condition or the action part - specified by the |
|
interface. |
|
* The action and condition plugin are a so called "AbstractPlugin" which means |
|
they have to be implemented by modules to be actually usable. In fact the |
|
callbacks provided by the action or condition implementation are |
|
incorporated in the plugin object using faces. That way an action or |
|
condition element behaves exactly like any other plugin instance. |
|
* Any rule element is an instance of a RulesPlugin. |
|
* A rules configuration consists of multiple rule elements while one is the |
|
root element, which may be a 'rule' but also any other plugin. |
|
* Each rules configuration may be persistently saved to the db using the |
|
entity CRUD API. Using the API on contained rule elements is working too and |
|
results in the whole configuration being updated. |
|
* Rules provides per plugin UI components, what makes the UI parts re-usable |
|
outside of the rule admin module too. In fact the rules admin module is |
|
pretty small, as it just relies on the provided UI of the components. |
|
* The UI is incorporated using the faces object extension mechanism, see |
|
rules_rules_plugin_info() for an overview of the used UI extenders.
|
|
|