[development] Actions in core

fago nuppla at zites.net
Wed May 2 21:04:00 UTC 2007

Am Mittwoch, den 02.05.2007, 15:34 -0500 schrieb John VanDyk:
> Although I am drawn towards greater and greater abstraction, I think 
> currently the best approach is to treat the current hooks themselves 
> as events. They already occur in predictable contexts and pass 
> predictable parameters. Modules are welcome to define their own hooks.
> >E.g. some of your default actions load the $node for the context
> >comment. Ideally that could be factored out of actions, so that a code
> >reacts on comment insertion/update, prepares the data and calls the
> >event, which fires configured actions / conditions.
> >What do you think about that?
> I think that as long as we have types of actions, we can factor it 
> out. For example, you know an action of type "Node" such as "Promote 
> node to front page" is going to need a node to act upon. Thus, you 
> can factor out the process that goes "Hey, this action is being 
> called during the comment-insert hook/op combination and the node is 
> not available; thus, pack the node into the context during the 
> action.module's implementation of the comment hook." However, you 
> have to be very careful about this. The action itself knows the most 
> about what it needs, and we want to avoid stuffing everything and the 
> kitchen sink into the context just in case the action needs it.

I agree, that this has to be avoided.
I've just committed some basic code to my sandbox, that implements the
basic event concept like I have it in mind:

It auto-loads arguments only when they are needed. So modules define
events and the available arguments, as well as possible available
arguments that the system loads, if there are actions defined for it.
What's missing, is mapping the arguments to the actions..

This separates the "context" code out of the actions. Actually the
action isn't aware of the context, it just has to define the argument(s)
on which it wants to work.

So, not every action has to re-invent the wheel and support each
possible context - nevermind if we are invoked from the comment hook
implementation or not! The action gets the argument(s) and can just do
its work :)

> >  > The next major hurdle for actions consists of action sets and
> >>  conditionals. Action sets are groups of actions that go together.
> >>  Conditionals evaluate and determine whether an action set actually
> >>  executes. eaton has paved the way for both of these in his voting
> >>  actions module. Unless we're very busy bees, that will have to wait
> >>  for Drupal 7.
> >
> >My concept also builds upons conditions. Perhaps I can help, so that we
> >could already get it into drupal 6 :)
> >
> >If you are interested in my help on this -
> >Where can I reach you for talking about this stuff?
> I've created a group at http://groups.drupal.org/actions for such discussions.
I suggest moving this discussion over there.


More information about the development mailing list