[development] hook_nodeapi()

[Rob Barreca]

> 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 at 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?