dragonchild has asked for the wisdom of the Perl Monks concerning the following question:

I've got a bunch of C::A subclasses and am serving them up under ModPerl::Registry. I'd like to have them be registered as their own handlers. I was thinking that since they all inherit from the same class, I could put something like the following in the base: 
sub handler
{
    my $r = shift;

    my $rm = ## Somehow get runmode from MP2 ##
    print $self->$rm;

    return OK;
}

[download]
  1. Is there anything wrong with this approach?
  2. How would I get the RM from MP2? MP1?
  3. Is this something that could be put into the C::A baseclass?

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

Replies are listed 'Best First'.
Re: CGI::Application as a mod_perl handler
by samtregar (Abbot) on May 07, 2004 at 20:20 UTC
    Just do: 

      sub handler { 
     __PACKAGE__->new->run;
     return OK;
  }

    [download]

    CGI::Application will take care of figuring out which run-mode is active during run().

    -sam

[reply]
[d/l]
      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

[reply]
[d/l]
        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]

Back to Seekers of Perl Wisdom