Hello,

I just wanted to jump in, though the answers are already in the thread I think.

You could just define a hash at the top of the program, or a __DATA__ section at the bottom, or put settings into a separate module (like Site.pm). I tried those but don't recommend them for setting data values. Exported functions tend to crawl into Site.pm, and only you really know how to edit it. It requires a lot of discipline to use a separate module for your configuration, and it just confuses everyone else.

To make software bilingual I've often used a hand-rolled hash which just slurps data in from a two-column text file (skipping comments, and delimited by one or more spaces or tabs). This worked very well, in particular for storing UI error messages and bits of Japanese strings (I'd keep Japanese SJIS-encoded strings in the text file and call them up using an English hash key).

But for what you usually think of as settings I've had best luck with INI style files, sorry don't remember if it was AppConfig or Config::IniFiles. Lots of people can figure out how to edit them or already know how, and IIRC you can write back to the file too.

As it happens IIRC (I could be mistaken) the Config::IniFiles module also lets you specify defaults at the top that can be overwritten below. Anyway, I have had good experiences with it, and have used it to roll my own controller for the htdig search engine, to store information on 60 databases and what sites to spider, what languages to let users search in, etc. It is also very nice for small programs, and I've used it with a WxPerl GUI app which also worked quite well. It's been a while but IIRC I kept one copy of the INI file for defaults, and then let the user set defaults in the GUI which got written back to the INI file when they clicked the Save button. This was great.

Now I am using Catalyst and YAML. Even though YAML sounds easy it took me a while to understand mostly what is going on, and even so I have had to use the command line simulator sometimes. But I think people could figure that out too. It seems that YAML is great for catalyst because by nesting labels you can easily overwrite defaults in several different modules, due to the way it is unrolled on top of the app's shared data structure. So while I have not had long experience with it, it seems that YAML is better for storing small data structures too in your config file, so you get more out of it after you get used to it.

Much as XML is hyped, I've hated editing XML every time I had to. If humans are going to touch it I would stay away from XML, and go to YAML instead. As it happens, you are also human and it is refreshing to be able to change a config file instead of having to dive into a module and worrying about breaking things, etc.

Anyway, you may like to experiment a bit but I'd recommend INI or better yet, YAML.

Oh and here's that code I used for error messages, FWIW. (click the "download" link to view full-width lines). It was useful for making email response templates (munged with HTML::Template) and pull-down menu data like a list of prefectures. I also used it to simulate an apache-style config file for server settings, since you can put in comments. The note that SJIS can break is only true if you use a comma separated list in Japanese and don't use Japanese regex module. Free for you to use, it is quick but maybe better to first learn a little YAML before you miss out...!

Good luck, Matt 

sub loadtextconfig {

        # Read a text-based config file into a single-level hash, die 
+on disk error
        # Usage: loadtextconfig(\%myhash, $myfilename);
        # Note: SJIS CAN BREAK/bakemoji e.g. a comma separated list of
+ prefectures
        # Copyright 2001-2004 (c) Matt Rosin

        my ($href,$f)   = @_;
        my ($i,$j)              = (0,0);

        open(W,$f) || die  "Content-type: text/html\n\n ERROR: Could n
+ot open $f $!";
        while (<W>) {
                next if /^#/;                           # ignore comme
+nted lines
                $_ =~ s/\r|\n//g;                       # remove endin
+g carriage return and/or ne
wline
                s/^\s+//;                               # remove leadi
+ng whitespace
                s/\s+$//g;                              # remove trail
+ing whitespace
                next unless length;                     # skip blank l
+ines

                ($i,$j) = split(/\t/,$_,2);             # $j holds res
+t of line
                $j = "" unless (defined $j);
                $j =~ s/^\s+//;                         # remove leadi
+ng whitespace
                $href->{$i} = $j;
        }
        close(W);

        # print "loadtextconfig $f: <PRE>\n" . Dumper($href) . "</PRE>
+\n";
}

[download]

In reply to Re: Config Files in Perl by mattr
in thread Config Files in Perl by narashima

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.