Think about Loose Coupling | |
PerlMonks |
Re: Should you use a module to hold configuration items?by techcode (Hermit) |
on Sep 21, 2010 at 12:04 UTC ( [id://861050]=note: print w/replies, xml ) | Need Help?? |
When I was starting out, I used plain global variables for those things. Which of course meant that once the code is moved to a real server (opposed to running it on my own dev machine) I needed to change those.
Obviously that's rather lacking solution - so I turned in to using config files.
I'm not sure what module from CPAN I used (tried several), used it for a time, but actually got sick of having to watch out so I don't override the config files on the production server with the ones from my development machine. And this is especially boring since if you want to use SVN/GIT - you cant have the production being work folder and just do "svn up" to update it. You have to export it somewhere else, then copy all but the configuration files.
So then I actually started doing exactly what you wrote - having a Config.pm file holding just the config values. Depending on the need it's either just a couple of exported globals (if it's just a one Perl file script I don't even have a module - I just set the values in the script itself), or a dummy function returning just a hash(ref) with all the config values. That way I have all the configurations for all the locations where the code would run - all in one place - one .pm file. And I get to just "svn up" (or "svn export" if I can't afford .svn directories/files all around) on the production machine - and don't have to think about what files I shouldn't copy or such. And there is another + that in case I (dirtily but quickly) fix an error on the production server - I can just commit it back to the repository. I guess that could be a bad thing if you had a lot of servers - but even then you could make a module load a config file based on hostname - or throw out an error if it can't. O and you can also change the @INC path that way - though I try to have everything relatively placed (so "use lib './PerlLibs/;'" would work no matter what the server, or configure Perl for the "whole server", I've also run into occasions when this was needed:
Have you tried freelancing/outsourcing? Check out Scriptlance - I work there since 2003. For more info about Scriptlance and freelancing in general check out my home node.
In Section
Seekers of Perl Wisdom
|
|