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