fuzzyping has asked for the wisdom of the Perl Monks concerning the following question:

I've written a small cgi application that runs via mod_perl. In order to keep the main script maintainable, I want to move all of the global user settings to a separate file. I'd like to make it a perl package so that visitors are unable to read the file directly.

My first attempt was to move the vars into a new Config.pm file and call it from within my mod_perl startup.pl file. Unfortunately, it appears that the variables are not being imported to my namespace. Any suggestions on how to fix this (or do it better)?

The tail end of my startup.pl:

use lib qw(/var/www/blogapp);
use Config ();

1;

[download]

Example from Config.pm:

my $database = 'data/site.db';
my $tmplfile = 'templates/index.html';
my $blog_title = 'example.com';

1;

[download]

Error from webserver:

[Sat Sep  5 19:42:30 2009] [error] PerlRun: `HTML::Template->new() cal
+led with odd number of option parameters - should be of the form opti
+on => value at /blogapp/index.cgi line 13\n'

[download]

Line 13 from index.cgi:

my $template = HTML::Template->new(filename => $tmplfile, die_on_bad_p
+arams => 0);

[download]
-fp

Replies are listed 'Best First'.
Re: Using packages to store global configuration vars
by dsheroh (Monsignor) on Sep 06, 2009 at 10:51 UTC
    You're missing two things:

    1. As already mentioned, my vars are only visible within the same scope, pretty much no matter what you do. Use our instead if you want them to be visible in other packages or files.

    2. Just changing my to our will allow you to reference the variables from your main program as $Config::database. If you want to be able to use just $database in the main program, then the Config module will need to export them, using Exporter: 

    package Config;

use strict;
use warnings;

use base 'Exporter';
BEGIN {
  # Things to export by default - minimize this, if you use it at all
  our @EXPORT = qw( );
  # Things to export when the calling code requests them
  our @EXPORT_OK = qw( \$database \$tmplfile \$blog_title );
  # A handy way of grouping exported items
  our %EXPORT_TAGS = ( all => [ @EXPORT, @EXPORT_OK ] );
}

our $database = 'data/site.db';
our $tmplfile = 'templates/index.html';
our $blog_title = 'example.com';

1;

    [download]
    The main program, then, would start off with 
    #!/path/to/perl

use strict;
use warnings;

use lib qw(/var/www/blogapp);
use Config qw($database, $tmplfile, $blog_name);
# or just
# use Config qw(:all);
# if you want everything the Config module exports

    [download]
[reply]
[d/l]
[select]

      I tried using Exporter as you described above (great example, thanks) but Apache/mod_perl kept complaining that :all wasn't being exported.

      I gave up on this after a while and am trying to simply use our and call the vars with $Config::var. I'm getting the same error as before and there are no values associated with the variables. I added a print STDERR "database is $Config::database\n"; to demonstrate.

      Snippet from Config.pm:

      package Config.pm;
use strict;

###########################
# user options            #
###########################
our $database = 'data/site.db';
our $tmplfile = 'templates/index.html';

      [download]

      A couple snippets from index.cgi:

      use strict;
my $database = $Config::database;
my $tmplfile = $Config::tmplfile;
...
print STDERR "FOOBAR $Config::database\n";
my $template = HTML::Template->new(filename => $tmplfile, die_on_bad_p
+arams => 0);

      [download]

      And the error:

      FOOBAR 
[Sun Sep  6 05:30:35 2009] [error] PerlRun: `HTML::Template->new() cal
+led with odd number of option pa
rameters - should be of the form option => value at /blogapp/index.cgi
+ line 29\n'

      [download]
      -fp
[reply]
[d/l]
[select]
        The first possibility that comes to mind is that you may not have restarted apache. One of the disadvantages of mod_perl development is that it doesn't check for changes to your code, so it's likely to still be running the original version if you haven't. (There is a switch you can set in httpd.conf which helps with this, but I don't recall the incantation offhand.)

        The second is that, in your original question, you said you had use Config at "The tail end of [your] startup.pl". Unless something else has caused Config.pm to be loaded earlier in your startup process, the perl compiler won't know about anything from Config until it hits that use line. Move use Config up towards the top of your code, so that it appears before any references to the variables in Config.pm, and it should take care of that problem.

        If neither of those things resolves your problem, try stripping both startup.pl and Config.pm down to the bare minimum necessary to demonstrate the issue and post them in full (not just snippets) so that we can see exactly what's going on. Unless, that is, you find a solution while you're in the process of creating your minimum failing case...

[reply]
[d/l]
[select]
        Most likely you're calling the core module Config, you should adjust your @INC path accordingly.

        UPDATE: ...or just rename your configuration file and package .

        Cheers Rolf

[reply]
Re: Using packages to store global configuration vars
by ikegami (Patriarch) on Sep 06, 2009 at 09:41 UTC

    How come you're not using use strict;? It would have told you you were using variables that don't exist.

    Lexical (my) variables are only visible to the scope in which they are declared. That scope is the file scope in this case. In fact, the variables don't even exist by the time you try to use it since Perl freed them when there ceased to be any reference to them.

[reply]
[d/l]

Back to Seekers of Perl Wisdom