Add support for task handlers and event dispatchers.

+++ b/rules_scheduler/includes/rules_scheduler.handler.inc
@@ -0,0 +1,74 @@
+ * Interface for scheduled task handlers.
+ */
+interface RulesSchedulerTaskHandlerInterface {

This should give an examaple of what task handlers are good for.

+++ b/rules_scheduler/includes/rules_scheduler.handler.inc
@@ -0,0 +1,74 @@
+   * Hook for processing a task after it has been queued.

That's not a hook. Also what kind of processing would one do here, maybe it would be good to state an example.

+++ b/rules_scheduler/rules_scheduler.install
@@ -123,6 +129,30 @@ function rules_scheduler_update_7202() {
+function rules_scheduler_update_7204() {
+  db_change_field('rules_scheduler', 'state', 'data', array(

That's problematic as it does not account for people's data. Maybe we provide fallback logic that can treat $data as $state for BC?

+++ b/rules_scheduler/rules_scheduler.module
@@ -22,10 +23,10 @@ function rules_scheduler_cron() {
+      $class = !empty($task['handler']) ? $task['handler'] : 'RulesSchedulerDefaultTaskHandler';
+      $handler = new $class($task);

this is repeated at least twice - can we have a helper to get the task handler from a task array? That also helps with possible later changes.

Patch looks good. We'll need tests for that though.

Dependency #2024257: RulesTriggerableInterface and RulesReactionRule changed as support for event settings have been added made it in.

+++ b/includes/rules.core.inc
@@ -239,7 +262,36 @@ class RulesEntityController extends EntityAPIControllerExportable {
+        // Only process each event once.
+        if (in_array($event_name, $processed)) {
+          continue;
+        }
+        $processed[$event_name] = TRUE;

That's not going to work.

+++ b/includes/rules.event.inc
@@ -125,6 +125,46 @@ interface RulesEventHandlerInterface {
+   * Returns the name of the event the event handler belongs to.
+   *
+   * @return string
+   *   The name of the event the event handler belongs to.

Base event name or configured event name? This should be clear.

+++ b/rules_scheduler/includes/rules_scheduler.handler.inc
@@ -0,0 +1,89 @@
+ * Default scheduled task handler.
+ */
+class RulesSchedulerDefaultTaskHandler implements RulesSchedulerTaskHandlerInterface {

What is the default behaviour? :)

+++ b/rules_scheduler/rules_scheduler.rules.inc
@@ -89,7 +89,7 @@ function rules_scheduler_action_schedule($args, $element) {
-      'state' => $new_state,
+      'data' => $new_state,

This does not match the docs of rules_scheduler_schedule_task() - but anyway it's an API change we should better avoid.

-> let's better keep it work with that function signature.

Also, there is no API function to create a task with a given handler. Dependent on the handler we will have different task settings/data, so maybe we add one and just document the required keys while handler can support new keys. Then, I think it makes sense to let the handler write the queue item, such that it can calculate dates etc. if necessary.

+++ b/rules_scheduler/rules_scheduler.module
@@ -53,11 +51,25 @@ function rules_scheduler_cron_queue_info() {
-  $handler = new $class($task);
-  $handler->runTask($task);

Quite important doc-block improvement ;-)

+++ b/includes/rules.core.inc
@@ -265,19 +265,12 @@ class RulesEntityController extends EntityAPIControllerExportable {
-        // Only process each event once.
-        if (in_array($event_name, $processed)) {
-          continue;
-        }
-        $processed[$event_name] = TRUE;

Now one event handler might be invoked multiple times?

Thanks, committed.