[development] Hook ordering

[Fernando Silva]

Hi,

I should completely clear up one point: I do not want to change the
systems I just propose to *unify* and *clarify* them (unfortunately
that means change the current code)!

A1. in the beginning I (wrongly) assumed that nodeapi() was the new
API that unified in a single place the work with both node (full node
type) and fields (fields added as a way to extend node functionality)

A2. You guys helped by showing me the differences. So I assumed that I
should use hook#operator() when working with nodes and
_nodeapi(op=operator) when working with fields

A3. The first problem of this orthogonal system, is that with the
evolution it got we can easily forget to update both systems with the
required hooks, examples: "delete revision",  "search result" and "rss
item"; forcing developers to make patches or use both hooks.

A4. A nice and *orthogonal* system implies more code to maintain than
a nice and *straight* system.

A5. The second problem, is that is too easy to mix how this orthogonal
system works. In fact some of you say that we should go with CCK
fields to create new nodes, and in this case what is reason to have a
system to work with nodes instead of only fields?!

A6. This complex problem is result of insufficient documentation, a
node system that has it's fully potential locked to the fear of
changes, insufficient programmatic use of the node system by contrib
developers.

What I propose is the following (after reading all the messages here):
P1. implement *all* hooks as hook_node#operator() -- eg.
hook_node_load() -- which solves the naming scheme.
P2. remove of _nodeapi(op=operator) which simplifies the system
P3. add to the hook_node#operator() a parameter "when", allowing *all*
modules to intercept "before" and/or "after" the event itself. Today
with nodeapi(), we can only intercept "after".
P4. Have the same functions to work the same logical way, helps doing
a better documentation that is easier to understand. The
hook_node#operator() would work with both complete nodes and extension
fields.

Think a bit... what can we do with the certain that we can intercept
hooks "before", "on" and "after"?!

Conclusion: I do not want to only do a simple name change. I'm
proposing the leverage of the node system, so it can be more useful to
implement much more flexible modules and easier to maintain.

Regards,
  Fernando Silva

On 1/5/07, Karoly Negyesi <karoly at negyesi.net> wrote:
> > * why do have we to use both?
>
> Because http://drupal.org/node/50627 got little love. We are not perfect. Working on it though.
>
> > * if one will stand up, what will be?
>
> Both will stand up.
>
> > Now, as I can see what you want is remove "nodeapi" stuff and convert
> > it for the hook_node_foo naming scheme. Nice, I'll help you with that:
> > * hook_load -> hook_node_load($when)
> > * hook_insert -> hook_node_insert($when)
> > * hook_nodeapi(op) -> hook_node_op($when)
> > * etc, etc, etc
>
> Still no.
>
> If teddy.module implements a node type then teddy_load remains. Just I am trying to find a better name to call this, because the hook part of hook_load does not really fit. As said, functor came to my mind -- functor_load. Might be a bad idea. Do not know yet. It took me five years to get a good translation in Hungarian for the word 'bully'... Reason for this change: hook is something that is called by module_invoke_all or similar. Code change: zero. This is a documentation change.
>
> But, if event module wants to add events to teddy nodes then it currently acts on hook_nodeapi op load. It's a true hook. Currently I think we would be better off calling this hook_node_load. Reason for this change: easier to fit into hook registry/order system. But then again -- hook_nodeapi#load could also be ordered. Just feel clumsy. Code change: for more complex modules, extremely little -- they have their handlers for different ops in different functions already.
>
> If you want to further this discussion then give me reasons why your change is better than the current, nice, orthogonal system. I am not changing the system at all, just renaming stuff a little bit.
>