Re: [cgiapp] Re: positional plugin ordering

[Cees Hek <suppressed>]

I think that all the suggestion so far still fail to consider the fact
that ordering will still be done based on @ISA order.  So regardless
of whether you have an 'after' hook, you still have the issue that
there may be an 'after' callback registered in two packages, and hence
the order of those two callbacks is fixed depending on the @ISA
hierarchy.  So you would have to have an 'after_after' hook to take
care of that.

I think that if we want complete control over ordering (ie maximal
flexibility), then we need to find a way where at 'call_hook' time we
gather all of the callbacks that need to be executed at that hook
location, and we run a method that sorts them into the desired order. 
I think trying to order then as they are registered will just run into
really awkward coding practices (for example say we want a config
plugin for all packages in our application, but because of ordering
constraints we need to load it in every package, instead of just in
the base class so we can get the execution order of the callback
correct)


I also thing that regardless of what consensus we come to, there will
always need to be some communication between plugin authors that want
to inter work with other plugins.

This brings me back to what I think would be the simplest (yet still
completely flexible) system that Michael Graham proposed way back
when, and that is to use a numbering system for the order.  This only
needs to be used by plugin authors that know that ordering is
important.  End users don't ever have to deal with it, unless they are
doing things that also require strict ordering.

__PACKAGE__->add_callback('postrun', \&my_callback, -300);

or for clarity if we moved to named parameters:

__PACKAGE__->add_callback(
      hook => 'postrun', 
      callback => \&my_callback, -300);
      order => -300,  # defaults to 0
);

at 'call_hook' time we can gather all callbacks registered in all
packages in the inheritance tree, and order them by their specified
ordering number.

This is how test scripts are ordered (by the name of their file, which
by convention starts with a number), and also SYS V init scripts also
use this system for ordering the execution of startup scripts at boot
time and shutdown time.

We can position all callbacks that don't care about ordering at 0. 
This means negative numbers will be executed before, and positive
after.  So to get back to the example of the HTMLTidy plugin, the
callback order could be set to some ridiculously high number like
100,000, but if someone came along and built a 'HTMLTidy_cleanup'
plugin that fixes some problems with the way HTMLTidy alters the HTML,
they could register their callback at 110,000 and it would still be
executed in the desired order.

What this doesn't solve is the issue where a plugin needs to do
something different based on whether another plugin is being used or
not.  ie the DBH plugin may look to a configuration plugin for
database info, but only if it is in use.  But I think that is a
separate issue and is only loosely related to callback ordering.


If you commented against this system the last time it was discussed,
look it over again, and feel free to make the same arguements again,
so that others don't have to look through the archives for the
counterpoints...

Cheers,

Cees

---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed