|Pathologically Eclectic Rubbish Lister|
Namespace repair - better way to do it?by meraxes (Friar)
|on Feb 27, 2008 at 16:55 UTC||Need Help??|
meraxes has asked for the
wisdom of the Perl Monks concerning the following question:
Hello fellow monks,
I've basically got a request concerning structure and what I'm tasked to do. I've got something... I just don't know if it's a good idea. So let me break it down to a kind of base case.
What I've got
I've got a CGI::Application-based app that we run several instances of under mod_perl. Each instance of the app gets it's own apache instance. Why not run more than one instance of the app under one Apache with mod_perl? Namespace.
Let say I have a CGI::App class for the app, Base::MainApp, and an OO module called Base::FooBar. The app doesn't run directly off of Base::MainApp but rather off subclasses of it. In this case lets say these subclasses are in folders like so:
+-modules/ | +-Base/ | | | +-MainApp.pm | | | +-FooBar.pm | +-Client1/ | | | +-MainApp.pm | | | +-FooBar.pm | +-Client2/ | +-MainApp.pm | +-FooBar.pm
So we have Base::Mainapp and Base::FooBar. But here's the kicker. Client1::MainApp is a subclass of Base::MainApp but Client1::MainApp is really just the package MainApp; ... and the same goes for MainApp in the Client2 folder. You see, all the startup.pl files for each instance of the App do the following:
Obviously, if this was to be an instance of Client2, the startup.pl would be changed accordingly. So, MainApp occupies the same namespace in Client1 as it does in Client2 which means I can't load both at the same time into the same apache instance under mod_perl.
What I've got to do
The app is structured this way because modules in each of the Client folders are like this:
This is so methods in Base::MainApp can be overridden to allow for custom behaviour in the app on a client by client basis. This is done extensively. Obviously, there's a lot more classes but this is how it works now.
The problem lies in Base::MainApp. In Base::MainApp you'll find use FooBar and $foobar = FooBar->new(). If we're running using Client1, this loads the FooBar.pm in the Client1 folder that is a subclass of Base::Foobar with any Client1 customizations. If I change Foobar to be Client1::FooBar, I can't use it!
What I'm doing... but is this a good way? Is there a better way?
So the namespace of the current client is in an environment variable; let's call it APP_NAMESPACE. Instead of a use statement inside Base::MainApp I'm using UNIVERSAL::require in the runmode that needs to access Client1::FooBar, so it's something like this:
I've made up a little testy thing with all these modules and all seems to work just as I expected but haven't started implementing this at large in the App. The intent is to do this with as low an impact to the codebase as possible but really I'd like to know if what I'm doing is a colossal boondoggle or not. Any alternate suggestions? Are there gotcha's I'm introducing with this? Are there gotcha's I don't know about concerning UNIVERSAL::require?
Update: Made a few grammatical fixes. I still let my mind run ahead of my typing.