continuing the discussion from http://lists.drupal.org/pipermail/development/2007-May/023657.html
code: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/fago/workflow...
The next steps would be:
* let actions define which arguments they need
* Collect assigned actions for events
* Map the arguments appropriately
I'd also like to have a look at implementing conditions. Ideally they would sit between events and arguments. We could also implement them as an action, that fires other actions if the conditions match. But this makes efficient argument handling more difficult - as actions have fixed arguments, but the arguments of configured conditions change - but it's possible.
That all would allow us furthermore to:
* let actions work on multiple arguments
* as well as on different arguments, but only on supported "entities", e.g. nodes, comments, users
Note that this also opens a lot of new possibilities. E.g. the node update event already offers support for working on the unchanged node! This enables conditions to react on changes! Define an action that informs the node author, if some one changes the title ? - an easy task. No need for coding a new action, just reuse the "send mail" action.
So in my opinion this helps a lot making actions a lot more useful - use them in any case, where suitable arguments are available.
Actually I had planned to code this anyway, as I have it's part of my bachelor thesis. The better if drupal 6 could benefit of it!
Comments
actions...
Here are some ideas for actions, in conjunction with the events:
-> The arguments are 1. 'comment' and 'node'
-> The action doesn't modify the comment, but the node. It returns array('node' => $node) - which will be passed to the next actions and in the end it will be saved using node_save(). Of course this will only be possible for supported entities (node, user, comments) - but it would enable us to batch different kind of actions that modify the same node!
The current batching system could be kept for batching use with things that are no known entities, but I think we would have simplified and improved the usual case of batching saving a node/user/comment.