The Actions API is now officially part of Drupal 6, and it's a tremendously powerful addition that (I think) will bear lots of fruit over the D6 life cycle. Things like custom workflow management solutions, streamlined application-specific user and content administration panels, and so on are all easy to build on top of the Actions API. However, the current implementation has a couple of subtle issues that cripple it for broad use. Our pattern for core constructs (menus and paths in particular) is to provide a foo.inc file that exposes a core API, and an optional foo.module that provides additional advanced customization options. Actions in D6 follows this pattern, but there appear to be a number of unintentional dependencies between the .inc file and the .module file. Specifically, action-related tables are never created, and action data is never initialized, until actions.module is installed. This means that actions.module -- which is only ONE possible application of the Actions API, and one that is unnecessary for many sites -- becomes an absolute requirement. Webchick and I have built a patch that fixes this, moving the truly core actions API functions into the .inc file, moving one setup screen into system.module, and keeping the advanced hook-to-action mapping UI in the optional actions.module. The patch also fixes a number of schema related issues and code style problems that chx has pointed out in the past. I'd encourage everyone who's interested in a powerful and flexible Actions infrastructure to check out http://drupal.org/node/155828 ;-) Thanks!
Webchick and I have built a patch that fixes this, moving the truly core actions API functions into the .inc file, moving one setup screen into system.module, and keeping the advanced hook-to-action mapping UI in the optional actions.module. The patch also fixes a number of schema related issues and code style problems that chx has pointed out in the past.
If modules can't assign actions to hooks, what are modules supposed to do with the actions API? Retrieve configured actions and fire them theirself? Sry for the probably dumb question, but I'd like to get this right. thanks, fago
Extensive docs on actions coming next week.
Webchick and I have built a patch that fixes this, moving the truly core actions API functions into the .inc file, moving one setup screen into system.module, and keeping the advanced hook-to-action mapping UI in the optional actions.module. The patch also fixes a number of schema related issues and code style problems that chx has pointed out in the past.
If modules can't assign actions to hooks, what are modules supposed to do with the actions API? Retrieve configured actions and fire them theirself?
Sry for the probably dumb question, but I'd like to get this right.
thanks, fago
Am Freitag, den 20.07.2007, 08:31 -0500 schrieb John VanDyk:
Extensive docs on actions coming next week. Great.
If modules can't assign actions to hooks, what are modules supposed to do with the actions API? Retrieve configured actions and fire them theirself?
Sry for the probably dumb question, but I'd like to get this right. Hm it seems that it's a too complicated question to get a short answer.
I guess it's only about executing actions. But should it be possible to execute configured actions or even to configure actions with a module? -fago
At 8:31 AM -0500 7/20/07, John VanDyk wrote:
Extensive docs on actions coming next week.
That was a long week. Here are some initial docs that are technical in nature. http://drupal.org/node/172152
Actions are a way of abstracting discrete, granular tasks like publishing or unpublishing a node, bookmarking a url, sending a node's url to an administrator, adding points to a user's UserPoints account, changing the author of a node, adding roles to a user, and so on. One application of these granular actions is mapping them to hooks. (IE, whenver a node is published, do <x>.) But Actions are useful ANY TIME you want to display a list of domain-specific tasks for the user to choose from. Views-Actions, for example, lets you add a button to any list or table view that initiates a given action. That allows admins to build a no-code-required roll-your-own-content-management- dashboard using a filtered view. Quite a few places in core can benefit as well -- the node and user admin screens, where we show a full list of users and a list of recent content, currently implement their own custom APIs for adding items to the 'what should I do with the things you selected' dropdowns. Instead, we should simply list all <node actions> or all <user actions> in those lists. That makes it dirt simple to add new items, and for other portions of the system to reuse the code that drives THAT admin panel. flagged-content is an excellent example module, as well. It lets users flag content as offensive, but it requires its own UI and its own code for handling 'what happens after a node gets flagged.' By leveraging actions, it could simply display a list of <node actions> and fire off whatever ones the admin has set up. Actions.module -- the one in core that maps hook_user, hook_nodeapi, hook_comment, and hook_cron operations to arbitrary actions -- is one of many applications of the Actions API. --Jeff On Jul 20, 2007, at 7:56 AM, fago wrote:
Webchick and I have built a patch that fixes this, moving the truly core actions API functions into the .inc file, moving one setup screen into system.module, and keeping the advanced hook-to-action mapping UI in the optional actions.module. The patch also fixes a number of schema related issues and code style problems that chx has pointed out in the past.
If modules can't assign actions to hooks, what are modules supposed to do with the actions API? Retrieve configured actions and fire them theirself?
Sry for the probably dumb question, but I'd like to get this right.
thanks, fago
Am Freitag, den 20.07.2007, 11:23 -0500 schrieb Jeff Eaton:
Actions are a way of abstracting discrete, granular tasks like publishing or unpublishing a node, bookmarking a url, sending a node's url to an administrator, adding points to a user's UserPoints account, changing the author of a node, adding roles to a user, and so on.
One application of these granular actions is mapping them to hooks. (IE, whenver a node is published, do <x>.) But Actions are useful ANY TIME you want to display a list of domain-specific tasks for the user to choose from. Views-Actions, for example, lets you add a button to any list or table view that initiates a given action. That allows admins to build a no-code-required roll-your-own-content-management- dashboard using a filtered view.
Quite a few places in core can benefit as well -- the node and user admin screens, where we show a full list of users and a list of recent content, currently implement their own custom APIs for adding items to the 'what should I do with the things you selected' dropdowns. Instead, we should simply list all <node actions> or all <user actions> in those lists. That makes it dirt simple to add new items, and for other portions of the system to reuse the code that drives THAT admin panel.
Actions.module -- the one in core that maps hook_user, hook_nodeapi, hook_comment, and hook_cron operations to arbitrary actions -- is one of many applications of the Actions API.
Thanks for that explanation! So in short, modules should be able to execute actions and if I got it right also already configured actions. I would have another application, execute actions on workflow-ng events. However, I think it would be better to handle action configuration storage with workflow-ng itself, but that should be doable.
flagged-content is an excellent example module, as well. It lets users flag content as offensive, but it requires its own UI and its own code for handling 'what happens after a node gets flagged.' By leveraging actions, it could simply display a list of <node actions> and fire off whatever ones the admin has set up. This is an awesome idea I wasn't thinking of.. That would be really useful, thanks. Perhaps I'll add it to workflow-ng or build a small extension module that just generates the event when the user clicks the link.
regards, fago
participants (3)
-
fago -
Jeff Eaton -
John VanDyk