Re: Re: CGI::Application as a mod

So, why isn't this part of C::A? Would it be appropriate to have it as a method in C::A?

Also, shouldn't it be:

sub handler {
    my $proto = shift;
    $class = ref $proto || $proto;
    $class->new( @_ )->run;
    return OK;
}
[download]

I'm thinking that would allow for both inheritance and for parameters to be passed in ... or am I missing something?

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

Comment on Re: Re: CGI::Application as a mod_perl handler Download Code

Replies are listed 'Best First'.
Re^3: CGI::Application as a mod_perl handler by adrianh (Chancellor) on May 08, 2004 at 08:42 UTC
So, why isn't this part of C::A? I'd say for three reasons: Not all CGI::Applications are mod_perl applications so why eat up the namespace by default mod_perl handlers don't have to be called `handler` so it won't be useful to all mod_perl applications There are two separate calling styles for mod_perl handlers (see below) so which one should be supported? A default handler makes less sense since you're likely to want to extract stuff from the request object at object creation time. I'm thinking that would allow for both inheritance and for parameters to be passed in ... or am I missing something? You're missing something ;-) mod_perl handlers are called in two ways. 1) As subroutines where an Apache object is passed as the first argument. It's not treated as a method call and the method that samtregar outlined would be the best approach. 2) As methods where the simplest approach would be to do something like: `sub handler { my $proto = shift; my $class = ref $proto \|\| $proto; $class->new->run; };` [download] In either case there aren't any extra key/value pairs passed to the handler that you can pass on to `new`. All you have is the request object which you'd need to munge yourself if you wanted to get anything out of it to pass to your C::A instance.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^3: CGI::Application as a mod_perl handler
by adrianh (Chancellor) on May 08, 2004 at 08:42 UTC

So, why isn't this part of C::A?

I'd say for three reasons:

Not all CGI::Applications are mod_perl applications so why eat up the namespace by default
mod_perl handlers don't have to be called handler so it won't be useful to all mod_perl applications
There are two separate calling styles for mod_perl handlers (see below) so which one should be supported?
A default handler makes less sense since you're likely to want to extract stuff from the request object at object creation time.

I'm thinking that would allow for both inheritance and for parameters to be passed in ... or am I missing something?

You're missing something ;-)

mod_perl handlers are called in two ways.

1) As subroutines where an Apache object is passed as the first argument. It's not treated as a method call and the method that samtregar outlined would be the best approach.

2) As methods where the simplest approach would be to do something like:

sub handler {
    my $proto = shift;
    my $class = ref $proto || $proto;
    $class->new->run;
};
[download]

In either case there aren't any extra key/value pairs passed to the handler that you can pass on to new. All you have is the request object which you'd need to munge yourself if you wanted to get anything out of it to pass to your C::A instance.

[reply]
[d/l]
[select]