Re: [cgiapp] Re: RFC: CGI::Application::RunModeCache

[Cees Hek <suppressed>]

Quoting William McKee <suppressed>:
> This forwarding of an event is not necessary developer unfriendly. I
> have experience with an environment (formerly known as Asymmetrix
> Toolbook) in which event messages had to be explicitly forwarded. You
> forget occasionally but the unexpected results are fairly obvious. As a
> developer, you learn that if you want the event to be handled upstream,
> then forward it.

Personally I think it will cause a lot of confusion.  Lets say I already have a
working app based on CGI::Application, and say I have used cgiapp_prerun in
several of my runmode subclasses.  Now I find there is a third party CGI::App
module that implements Authentication that I want to use, and it happens to need
the cgiapp_prerun mode as well.  In order for me to use this module, I have to
go through all my code and add $self->SUPER::cgiapp_prerun() to all my
cgiapp_prerun methods.

If I miss the part in the docs where it tells me to do that, I may get
frustrated with the module, because it "does not work as advertised".  I
shouldn't have to alter any code that has nothing to do with Authentication just
to use this module.

> At other times, it's rather convenient to capture the event not have it
> forwarded up the chain. I'm indifferent about the basic philosophy
> (automatic forwarding of events vs. manual forwarding) but would expect
> to have a way to override whatever is the chosen default.

Thats true, but that could be done with a subclass and overriding the method. 
for example, lets use the authentication module example again.  If I use
CGI::App::Auth and I want to capture the cgiapp_prerun method it uses and do my
own thing instead, then I create a subclass of CGI::App::Auth and override it's
cgiapp_runmode method and use the subclass in my modules instead.
 
> Also, you mentioned that you modelled the patch on mod_perl's bins. I'm
> not familiar enough with these to know whether they allow multiple
> handlers to handle an event. It seems that was one of the features I've
> seen mentioned in regards to mp2. Is this chaining of an event a manual
> or automatic process?

Yes, mod_perl allows for multiple handlers at each stage, and it allows you to
suggest the order that they execute in.  It adds a few more features as well,
like being able to short circuit the chain based on return values, but I thought
that would complicate CGI::Application too much without enough gain in
functionality.  

As for whether it is automatic or manual, that depends on how you look at it. 
If I use a third party mod_perl module that does authentication, then when I
load that module in the Apache startup script, it can register itself
automatically as an AuthHandler.  So in that sense it is automatic.

mod_perl1 provides three methods to use for registering handlers:
get_handlers
set_handlers
push_handlers

http://perl.apache.org/docs/1.0/api/Apache.html#_r_E_gt_get_handlers___hook__

In mod_perl2 this was altered to allow for more flexibility (This hasn't been
fully stabilized yet, so there may be more changes).

Apache::Hook->add(PerlAuthenHandler => \&authenticate,
                    Apache::Hook::MIDDLE);

http://perl.apache.org/docs/2.0/user/intro/overview.html#What_s_new_in_Apache_2_0

The documentation on this stuff may be out of date.  I am not sure, because I
haven't done much work with handlers in mod_perl2 yet.

Hope that answers your questions.

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