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?

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? :)