[cgiapp] Re: positional plugin ordering

[Mark Stosberg <suppressed>]

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:

1. Needing to execute after another plugin, such as connecting to the db
   only after the configuration is done. 

This is not so hard, because you can check %INC to see if a
module is loaded, or use the proposed hook_exists() method as well. 

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

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: 

  sub cgiapp_postrun {
    my ($self, $contentref) = @_;
    $self->SUPER::cgiapp_postrun($contentref);
    $self->htmltidy_clean($contentref);
  }


    Mark

-- 
http://mark.stosberg.com/ 


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