ServersThe Perl Basics You Need To Know Page 3

The Perl Basics You Need To Know Page 3

ServerWatch content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.




Now in packages that want to use the configuration variables I have either
to use the fully qualified names like ::Config::test, which I
dislike or import them as described in the previous section. But hey, since I
have only one variable to handle, I can make things even simpler and save the
loading of the Exporter.pmpackage. I will use the Perl aliasing
feature for exporting and saving the keystrokes:

  package My::HTML;
  use strict;
  use lib qw(.);
    # Global Configuration now aliased to global %c
  use My::Config (); # My/Config.pm in the same dir as script.pl
  use vars qw(%c);
  *c = %My::Config::c;
  
    # Now you can access the variables from the My::Config
  print {scalar_var};
  print {array_var}[0];
  print {hash_var}{foo};

Of course is global everywhere you use it as described
above, and if you change it somewhere it will affect any other packages you
have aliased ::Config::c to.

Note that aliases work either with global or local() vars–you
cannot write:

  my *c = %My::Config::c; # ERROR!

Which is an error. But you can write:

  local *c = %My::Config::c;

For more information about aliasing, refer to the Camel book, second
edition, pages 51-52.

Using Non-Hardcoded
Configuration Module Names

You have just seen how to use a configuration module for configuration
centralization and an easy access to the information stored in this module.
However, there is somewhat of a chicken-and-egg problem–how to let your other
modules know the name of this file? Hardcoding the name is brittle–if you have
only a single project it should be fine, but if you have more projects which
use different configurations and you will want to reuse their code you will
have to find all instances of the hardcoded name and replace it.

Another solution could be to have the same name for a configuration module,
like My::Config but putting a different copy of it into different
locations. But this won’t work under mod_perl because of the namespace
collision. You cannot load different modules which uses the same name, only the
first one will be loaded.

Luckily, there is another solution which allows us to stay flexible.
PerlSetVar comes to rescue. Just like with environment variables,
you can set server’s global Perl variables which can be retrieved from any
module and script. Those statements are placed into the httpd.conf
file. For example:

  PerlSetVar FooBaseDir       /home/httpd/foo
  PerlSetVar FooConfigModule  Foo::Config

Now I require() the file where the above configuration will be
used:

  PerlRequire /home/httpd/perl/startup.pl

In the startup.pl I might have the following code:

    # retrieve the configuration module path
  use Apache:
  my              = Apache->server;
  my       = ->dir_config('FooBaseDir')      || '';
  my  = ->dir_config('FooConfigModule') || '';
  die "FooBaseDir and FooConfigModule aren't set in httpd.conf" 
    unless  and ;
  
    # build the real path to the config module
  my  = "/";
   =~ s|::|/|;
   .= ".pm";
    # I have something like "/home/httpd/foo/Foo/Config.pm"
  
    # now I can pull in the configuration module
  require ;

Get the Free Newsletter!

Subscribe to Daily Tech Insider for top news, trends & analysis

Latest Posts

Related Stories