Posted by brmassa on July 16, 2009 at 11:21am
Guys,
Following Earl "merlinofchaos" Miles' Views and Panels, we are planning to code the new API using OOP (object oriented programming). It eliminates the need of callback functions, but also allow other modules to overwrite its functionalities and expand them using "plugins".
Originally, we planned to build an class similar to this:
<?php
/**
* There are several actions that users can perform navigating Drupal. Some
* are listed on hook_menu(), but most of them are not declared in a format that
* allows users to manipulated and call them or expose to external tools or
* other sites.
*
* This class describe the actual operation that can be done as well some metadata
* that can be used by other modules see what they do and how.
*/
class rulesAction {
/**
* List all values needed by this action. It should in the same order that
* the execute function requires. Each parameter should provide these attributes:
* * name => the variable name
* * type => the variable type
* * subtype => (optional) the variable subtype, in case the main type
* is too generic like being an object.
* * title => (optional) the variable's "human friendly" name
* * description => (optional) a small description
* * optional => (optional) TRUE if the parameter is optional
*
* @return
* Array. A list of all parameters needed by this action.
*/
public function arguments() {
return array(
array(
'name' => 'nid',
'type' => 'int',
'title' => t('Node ID'),
'description' => t('Node which will be modified.'),
),
array(
'name' => 'author',
'type' => 'object',
'subtype' => 'user',
'title' => t('Node author'),
'description' => t('User that created the node.'),
),
);
}
/**
* An optional list of this action attributes, such as:
* * return => (optional) the variable type what this action returns
* * title => (optional) the variable's "human friendly" name
* * description => (optional) a small description
*
* @return
* Array. A list of all extra arguments needed by this action.
*/
public function description() {
return array(
'title' => t('The example action'),
'description' => t('Do stuff with a node.'),
'return' => 'array'
);
}
/**
* Execute the action.
*/
public function execute() {}
}
?>But it might be necessary to add some other things, so if you think its needed something more, just say so.
regards,
massa
Comments
What are some use cases that
What are some use cases that would need those enhanced actions and that cannot be implemented using the existing API?
Modern
Karim,
the redesign is to reach 3 objectives:
1* Code reuse. Inviting other module developers that might perform similar things to unify and reuse code. So, Views Bulk Operation module might use the very same actions that are already defined on Rules. Or Web Services might export these actions as services.
2* New ideas. Based on item above, these other developers might have different problems or different ideas about how to create this new set.
3* Modern Object Oriented approach. It will not be visible for users, just for developers. Make the code more elegant.
I dont know if there any specific case that the current API is not adequate. But like image handling, actions might be highly enhanced if lot developers commit to a standardised solution.
regards,
massa
---
The object oriented approach has some advantages; the fact the Drupal 7 database API has been rewritten to use classes shows the approach can be used to write better code. It is surely better than code that checks the value contained in an array, which cannot be easily expanded.
I really wish that more modules would implement classes, even if sometimes classes cannot replace Drupal hooks, especially because hooks cannot be class methods.