[development] hook_nodeapi()

Jeremy Epstein jazepstein at gmail.com
Thu Jan 4 00:05:58 UTC 2007


On 1/4/07, Khalid B <kb at 2bits.com> wrote:
> 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?

Interesting ideas, Khalid. Your suggestions triggered me to think of
another possibility for how to overcome the node hooks problem:

4. We could remove all the hook_something() hooks, and for every
hook_nodeapi('something'), we could create a new
hook_nodeapi('something_alter'). Yep, that's right: YAAH (Yet Another
Alter Hook :P). When you think about it, hook_nodeapi() really is
already an 'alter' hook - why not change its name to more accurately
reflect its behaviour?

Module authors would then be encouraged to use
hook_nodeapi('something') only for node types that are 'owned' by
their module (but if module-defined node types disappear, then the
ownership will not be formal), and to use
hook_nodeapi('something_alter') for working with node types that are
'owned' by other modules. Obviously, all hook_nodeapi('something')
implementations will then run before hook_nodeapi('something_alter').

The advantage of this over the current system, is that modules can
assume ownership of user-defined node types, instead of only owning
node types that they formally define through hook_node_info(). For
example, event.module might assume ownership of custom node types that
have been set to be event types, and so it would use
hook_nodeapi('something'). Whereas upload.module wouldn't assume
ownership, and so it would use hook_nodeapi('something_alter').

The biggest disadvantage of this (which is quite obvious from looking
at the above example) is that it will be difficult to say when a
module should or shouldn't assume ownership of node types, and that it
will be easy for multiple modules to all assume ownership of node
types, which would basically render the ordering of the hooks
redundant (since none of them choose to use 'alter').

Cheers,
Jaza.


More information about the development mailing list