Re: [cgiapp] Re: positional plugin ordering

[Michael Peters <suppressed>]

Mark Stosberg wrote:
> On 2005-06-20, Michael Peters <suppressed> wrote:
> 
>>It seems to me that most use cases for plugin execution order aren't
>>about when something happens, but when it happens in relation to
>>something else.
> 
> 
> I agree this a key point. So far we have seen two use cases for plugin
> ordering:

[snip]

> 2. Needing to execute after an established phase, such as processing
>    output after postrun with HTML::Tidy.
> 
> This is more challenging. A solution was proposed to have an
> 'after_teardown' hook. However, I think we could run into problems
> because we are talking about a position relative to a generic phase,
> not a specific condition. It would seem we would be prone to want to add
> 'after_after_teardown' or 'really_after_teardown'.

I don't really think it would degenerate that far down for a few simple
reasons.

For any given phase it is possible to control when your plugin executes
it's callback relative to others by simple ordering of the 'use'
statements. If you really want it to go last, use it first. This does
not however work for the predefined hooks because class based hooks are
done in @ISA order, so a cgiapp_postrun() method will always run after
anything else registered in the 'postrun' hook.

> For now, I like the solution used the HTMLTidy plugin. It basically
> involves adding just one line of key code to an application:
> 
> use CGI::Application::Plugin::HtmlTidy;
>   
>   sub cgiapp_postrun {
>     my ($self, $contentref) = @_;
>     $self->htmltidy_clean($contentref);
>   }
> 
> That doesn't seem so bad to me. Are there big problems with this I'm overlooking? 
> I guess you might want to be careful and add a call to SUPER in case your parent class
> also had a postrun method defined: 

I really don't like this. It brings us back to the same boat we were in
before having plugins or a callback system. It becomes really hard to
distribute base classes, etc because you have to warn the user about
every method that they can't use or else they have to make sure to call
the parent method.

The real beauty about the callbacks is that they make plugins truly
invisible. What if I'm using the HtmlTidy plugin during development to
help me catch silly HTML errors from the final product. Then when I'm
moving to production I can't just simple comment out the 'use' line in
my base class (or base's base class, etc). I also have to track down any
child classes, etc that might be calling htmltidy_validate().

Here's another proposal, that I feel is simple and actually pretty neat
in the flexibility it allows.

call_hook would now look something like this:

sub call_hook {
   my $self      = shift;
   my $app_class = ref $self || $self;
   my $hook      = lc shift;
   my @args      = @_;

  # do what I was doing...
  ...
  # now after that
  if( $self->hook_exists("after_$hook") ) {
    $self->call_hook("after_$hook", @args);
  }
}

This would not only allow someone to create an 'after_' hook for any
other existing hook, but also take care of when it get's executed.

And in the extreme case when some plugin wants to make that they are the
absolute thing to run in a hook, they can do something like:

my $found_place_to_run = 0;
my $hook = 'teardown';

while( !$found_place_to_run ) {
  $hook = "after_$hook";
  if( !$self->hook_exists("$hook") ) {
    $self->create_hook( $hook );
    $self->add_callback( $hook => \&_some_sub );
    $found_place_to_run = 1;
  }
}

Although this could potentially create a hook named
'after_after_after_after_teardown' it would never be seen by anything
else and completely invisible to the end user.

Questions? Comments? Verbal Abuse?

-- 
Michael Peters
Developer
Plus Three, LP


---------------------------------------------------------------------
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