2a. Same as 2, but eliminate the nodeapi('something') that has an indispensible hook_something() equivalent. This way we are back to one way of doing things. But, we'll always need hook_nodeapi() so that my module can act on nodes defined by other modules. The confusion arises because you technically "could" write mynodemodule_nodeapi('insert') { if ($node->type == 'mynodemodule') ... } instead of mynodemodule_insert(), even though as it's been stated here that other nodeapi modules wouldn't have the full node available to them.
Rob Roy Barreca Founder and COO Electronic Insight Corporation http://www.electronicinsight.com rob@electronicinsight.com Khalid B wrote:
Speaking from personal experience, and having been confused by this duplication in the past, the problems as I see them are:
a. More than one way of doing things. This means that there is duplication between the hook_something() and hook_nodeapi('something').
b. This duplication causes confusion to many developers (myself included).
I will leave others to comment on the details codewise, but here are the options, in order of (my) preference:
1. Restricting node hooks to one way of doing things (hook_nodeapi). This means deprecating all hook_something() for node operations. This way there is no confusion.
2. Eliminating all the hook_something() that are duplicated by hook_nodeapi('something') and do not suffer the drawbacks listed above. This may mean leaving the node_load() hook, and maybe others, and that is fine by me. Less confusion.
2a. Same as 2, but eliminate the nodeapi('something') that has an indispensible hook_something() equivalent. This way we are back to one way of doing things.
3. If the present scheme MUST stay as it is, then I don't know if documentation improvement will be enough to overcome the drawbacks.
Other ideas?