If you've been a Drupal developer for a while you know that modules run according to the value of the weight field in the system table. You can update this table using an install file so your module runs exactly when you need it. This is what community tags does to run after tagadelic and the method I've used to make sure some form_alter code runs after everything else when I needed to modify event forms.

But the change in the module's weight affect all the hooks in it. What happens if you want to control the runnning order in a per hook basis? I needed to do this to run some nodeapi operations in a custom module before event_nodeapi and form_alter stuff, in the same module, after event_form_alter. Believe me, you may need this some time (unless you opt for using before and after modules).

This idea inspired me to code a bit and individually override the operations in event_nodeapi with some code in my custom module. It worked nice. Now I can run operations load and view in event_nodeapi and override insert and update with code from my module.

The concept is quite simple. I added an event_nodeapi_overriders table with two fields: module and op. My module just needs to use its install file to insert values in this table. If I want mymodule to provide overriders for insert and update operations in event_nodeapi I should add the following module/op pairs to the table: mymodule/insert and mymodule/update.

Then I added a few select boxes to show the values from event_nodeapi_overriders table in the event settings page where I can choose which module should override which operation and used some conditions with variable_get() in event_nodeapi and mymodule_nodeapi to decide which code to run.

Perhaps the concept could be extended to eventually have a matrix of all hooks in all modules or a hook_weight parameter to allow developers to decide the running order. Or maybe is too much overhead?

Anyway, this was some kind of experiment and even if after talking to Gerhard we decided to update the event module to use Form API in the submission process instead, the idea of having better control over hooks running order could deserve some more thinking.