DEVELOPER.txt 1.6 KB

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