in reply to Re^2: Subclassing Apache::Request?
in thread Subclassing Apache::Request?

How do I get the server to return my new object instead of a generic Apache object. Or, how do I get the server to return my object blessed as an Apache object, instead of returning a generic Apache::Request object?

I think the short answer is, you can't/don't. No matter how hard you try, handler() will always receive a vanilla Apache object

So the next best thing would be to always start out your handlers like so:

  sub handler {
     my $r    = shift;
     my $my_r = My::Apache::Request->new($r);
     # do interesting things with $my_r
  }

[download]

Or perhaps you can create something like the Apache->instance() method, and do something like:

   # somewhere in your code...
   my $r = My::Apache::Request->instance;

   # in My::Apache::Request;
   package My::Apache::Request;
   use base qw(Apache::Singleton); # or something like it 

   sub _new_instance {
      my $class = shift;
      return $class->new(r => Apache::Request->instance);
   }

[download]

Replies are listed 'Best First'.
Re^4: Subclassing Apache::Request?
by tadamec (Beadle) on Aug 11, 2004 at 09:00 UTC

    I'm thinking of mod_perl as a set of Perl objects to help you deal with passing stuff around an Apache application. My thinking is wrong, but it hasn't mattered until now.

    I've spent the last several years dealing with mod_perl on a daily basis, yet haven't hit a point yet where I've needed to know more about the internals than the simple cook-book recipies and how to set up a Mason handler that deals with virtual hosts nicely.

    What I'm really noticing now is a lack of documentation for mid-level mod_perl stuff. The things I'm trying to do seem a little more advanced than general mod_perl stuff, but nothing that should require delving into the C and XS code. All of my searching has come up with stuff that's either geared more towards getting started with mod_perl or turning around and doing actual tweaking of the mod_perl engine itself.

    Thanks for the help on this, by the way. It's been most illuminating.

[reply]
      The things I'm trying to do seem a little more advanced than general mod_perl stuff, but nothing that should require delving into the C and XS code.

      uh, right. you don't need to delve into C/XS. Whatever gave you that idea?

      If you want to create objects to handle generating content, just create a handler that instantiates an object: 

        package My::Handler;
  sub handler
  {
     my $r = shift;

     # translate from URL to package name, and the "action"
     # that you want to perform
     my($pkg, $action) = figure_out_package_name($r->uri);
     
     # instantiate, and call the appropriate handler
     my $obj = $pkg->new();
     $obj->dispatch($action);
  }

      [download]

      Meanwhile, if you still insist on subclassing Apache (which, I'm starting to think could be useful, but is still parallel to what you are trying to solve), you could just add a hook to do so in the dispatch() method above:

      
  sub dispatch
  {
     my($self, $action) = @_;
     my $my_r = My::Apache::Request->new(Apache->request);
     $self->do_the_appropriate_thing($action, $my_r);
  }

      [download]

      Then when you write code for the actual objects that handle the request, you can safely assume that you will get the appropriate request object. No?

[reply]
[d/l]
[select]

        Sorry, I've been trying to get this working all day and I'm tired; the response was phrased poorly.

        The XS/C comment was more on the lack of what I would consider medium-complexity mod_perl documentation. My searching is turning up documentation on how to get started with mod_perl, and how to understand mod_perl at the C/XS level. I'm not having any luck finding anything in between the two.

        I think the answer to the question I asked is: I asked the wrong question. My understanding on how mod_perl works weren't right, at least as far as this task is concerned.

        In this node, I refined the question as I understand it now. Briefly:

        Since the handler isn't really an object, what's the best way to go about creating a framework to make all of the various helper objects in our application more friendly to each other.

        Joost reccommended that I take a look at Apache::MVC for some ideas on how to handle this. I've played with OpenInteract and found it way too complicated to use in our situation, but I might just stumble on some new ideas in Apache::MVC.

        Meanwhile, if you still insist on subclassing Apache (which, I'm starting to think could be useful, but is still parallel to what you are trying to solve), you could just add a hook to do so in the dispatch() method above:

        I think I've come to a different conclusion based on this thread now; I'm also doubting that I've come to the right one. Because of the 42 different ways that various developers have done things throughout the lifespan of this application, I'm beginning to think that there's no simple fix to this.

        I was looking at subclassing Apache::Request as a simple method to encapsulate all of my nice "namespace-like" functionality (described in the linked node) to a class that's used in every single action throughout the app. It becomes a little bit simpler to fix the app if I can just go through and move all of the session munging into a few$r->some_method() calls.

        Does this make any more sense now, or should I go get a few hours of sleep? :)

[reply]
[d/l]

In Section Seekers of Perl Wisdom