Does the system.weight affect nodeapi as well? I need a module to load after another so this would be a perfect solution. On 6/7/06, Karoly Negyesi <karoly@negyesi.net> wrote:

On Wed, 07 Jun 2006 19:51:13 +0200, Gabor Hojtsy <gabor@hojtsy.hu> wrote:

...

understand it correctly is to name my module something post "p", so that it is called after the path module, or manually tinker with the weight of modules in the system table. Am I right, or are there better options?

system.weight has been added specifically for this purpose: altering altered forms. Use hook_install to set your system.weight accordingly.

Regards

NK

Op donderdag 8 juni 2006 05:19, schreef Karoly Negyesi:

Yes. system.weight defines calling order always.

weights aer nothing more then another layer. What if you alter an altered form, where the other one has a weight set? weights don't really solve any issue, they just move the issue of conflicts one level away. I beleive we should get rid of the weights in favour of something like: * roundtrips. A hook not only returns a value, but also a flag whether the current hook call should be * Stopped right now, and reran from start, but then containing the current data. * Continued and stopped after a complete roundtrip, just like Drupal does now. * Continued and reran after a complete roundtrip, but then containing the current data. This is particularly hard because you need to build in measures to not end in endless loops. * Hook registration. Instead of looking around if a hook exists on each pageload, all modules register their hooks. A central API *and* a UI can then allow us to reorder, switch on/off, ignore etc hooks. Yes, both are a lot of work. And no, I am not volunteering :) And yes,I feel I am alowed to speak about this, without actually coding it. -- | Bèr Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com | Drupal upgrade repareert kritiek beveiligingslek: http://help.sympal.nl/drupal_upgrade_repareert_kritiek_beveiligingslek

Yes. Messing around with weights is a stopgap solution for 4.7, but indeed we need something better. And order of operations is only getting more needed rather with less, as we work more with extending existing behaviours through form_alter, db_rewrite_sql, etc. A concrete example: I'm working with a module that wants to come after user.module but before node.module. Yes, I can reset the weights of one or both of those core modules, but it's an obvious hack that will fail as soon as someone else tries to do the same. An limited and trouble-prone alternative right now is to explicitly call another module's method. If, e.g., my form_alter needs to come before node.module's, I can call node_form_alter() at the end of my example_form_alter() call. The issue and both of Ber's suggestions seem worth some more attention. * roundtrips. * Hook registration. Key to this is that it isn't absolute order of modules that's the issue; it's the order of particular calls. It's quite feasible, for example, that example_form_alter needs to come before node_form_alter, but example_menu after node_menu. Maybe a simple (?) solution would be to register not all hooks but only their dependencies. function example_hook_dependencies() { return array( 'form_alter' => array( '#before' => array('node'), '#after' => array('user') ), 'menu' => array( '#before' => array('node') ) ); } (Or, alternately, I suppose, these data could be coded into an install metadata file.) Then module_invoke_all evaluates these dependencies and orders its calls accordingly.

On 6/10/06, Nedjo Rogers <nedjo@islandnet.com> wrote:

Maybe a simple (?) solution would be to register not all hooks but only their dependencies.

function example_hook_dependencies() { return array( 'form_alter' => array( '#before' => array('node'), '#after' => array('user') ), 'menu' => array( '#before' => array('node') ) ); }

This would be an extremely useful mechanism, and I think that for the vast majority of cases, it would work very well. However, there would be some cases where dependency conflicts could occur, and I envision that if/when these happen, they could potentially get very messy. E.g. let's say 3 modules in core (A, B, and C), have no dependencies defined for hook_form_alter(). Then the contrib modules D and E come along, and each define their own dependencies. How would this case be handled: - Module D's hook must be called after module A, and before modules B and C. - Module E's hook must be called after module C, and before module A. I can think of no clean solution to the problem above. But then again, I was never much good at those maths problem-solving puzzlers. Maybe the more outside-square-thinking among us can see a way around cases such as this. :p Cheers, Jaza.

Adrian Rossouw wrote:

On 09 Jun 2006, at 4:08 PM, Nedjo Rogers wrote:

...

(Or, alternately, I suppose, these data could be coded into an install metadata file.) My solution to the problem involves separating out the menu system, and it's actual nature.. the callback system.

Thus allowing you to register multiple callbacks, of different types.

It should be able to pick up what hooks a module implements when it is enabled, and then keep a pre-sorted callback order. (in the fapi callback format, preferably).

When it comes down to it, a hook is just an automatically registered callback. and the big problem with using a hook over a registered callback, is you have no way to give extra information about it.

Adrian - are you planning to work on this. Would be very very useful. Even if you wrote a design doc for it and left the coding to others. @Boris - Perhaps you can free up Adrian to work on this doc. Is a prerequisite for fapi 2.0.