I think the problem I was having was my understanding of exactly how mod_perl works. I've been operating under the assumption that I was getting an Apache::Request object when this, clearly, is not the case. Up until now, the distinction hasn't mattered, as I've been able to just treat the reference passed into the handler as an "object" and everything is fine.
What I'm running into now is trying to organize the ball of mud that the application has become. We have a set of application handlers that the actual Apache handler calls based some URI formatting rules. For example, the URI www.example.com/Foo/bar will instantiate a copy of a Foo object, call the bar method and pass the resulting values back to an instance of the Template Toolkit for display.
The problem comes into being when that object needs to forward calls to successive methods. For example, say the bar method needs to do some input validation and store the validated input for passing into the baz method.
We have no consistent methodology for doing this at the moment, other than the requirement that the tied hash of an Apache::Session object is passed into every method. We have some objects that will put the data they need into a named hashref underneath the session like so:
$SESSION->{Foo} = { Value => 94, name => 'Frank' }
While others will do the following:
$SESSION->{value} = 94;
$SESSION->{name} = 'Frank';
Where I run into bigger problems is when code uses a key like "validate". Some of the authentication code uses "validate" to insure that the user is logged in, while other functions set a "validate" key to mean that the variables have been validated. We have masses of special case if statements throughout the application to move these "magic" tokens around so we don't break other functionality. Obviously, it's a nasty situation that needs to be refactored.
My thinking was that I could subclass Apache::Request, place my session handling code within the subclass, and add a couple of methods to do things like add an application global setting, and a couple of helper functions for adding the object specialized stuff, above. Perhaps something like this:
# Set a global "login" variable
$r->set_global( Login => 1 );
# Do some other stuff, then let the Bar function do things.
$r->private_variable( Package => "Foo", Function => "Bar", Value => "S
+ome Value" );
This needs a bit more refinement, obviously, but I think it would solve some of our problems.
I'm imagining a set of functions that are easy to work with and make accessing values stored between requests logical instead of the chaotic approach that the application currently uses.
Is that a better explaination? |