Yeah I know. That irritated me too when I looked at the code. I haven't used Config::IniFiles myself (Config::General is the ticket for me), so my knowledge comes from a quick glance at the POD. That does however mention a tied interface so that you can say $ini{section}{directive} (for a tied %ini).

Actually, you did do a bit more than the modules in that Data::FormValidator will not take care of the template part of the job that transforms the input as hacker wants it. Still I think using the modules would be easier here. YMMV.

Makeshifts last the longest.

Withdrawn within 10 mins of posting when (almost) noone had seen my irrationality...

Wrong flame, wrong target. My profound apologies to Aristotle for having wrongly posted in reply to one of his posts thereby making it look as if my problem was his. It was not.

I just took a quick peek at Config::General's POD, and I notice there's a value there that can normalize the variables that are being passed in my template:

  -AutoTrue
   If set to a true value, then options in your config
   file, whose values are set to true or false values,
   will be normalised to 1 or 0 respectively.

   The following values will be considered as true:

      yes, on, 1, true

   The following values will be considered as false:

      no, off, 0, false

   This effect is case-insensitive, i.e. both "Yes" or "oN" 
   will result in 1.
[download]

Using this method, I may be able to cut down on 80% of my field validation in the original template. I'll give Config::General, Config::General::Interpolated and Config::General::Extended a look, they may be what I seek. Thanks for the tip!

Further testing now yields the following code (Aristotle++ for the suggestion of using this module, and valdez++ for helping me figure out why the keys weren't captured properly)

     use strict;
     use Data::Dumper;
     use Config::General;

     my $conf = new Config::General(
                   -ConfigFile      => 'template.ini',
                   -ExtendedAccess  => 1,
                   -InterPolateVars => 1,
                   -AutoTrue        => 1,
     );

     my %config = $conf->getall;

     my $template = $conf->obj('template');

     my $backup_bit          = $template->backup_bit;
     my $beamable            = $template->copyprevention_bit;
     my $bpp                 = $template->bpp;
     my $maxdepth            = $template->maxdepth;
     my $url                 = $template->url;
     my $title               = $template->title;
     my $launchable_bit      = $template->launchable_bit;
     my $no_url_info         = $template->no_url_info;
     my $avantgo             = $template->AvantGo;
     my $compression         = $template->compression;

     print Dumper(%config);

     __END__

     <template> 
       url                =   
       AvantGo            = No
       maxdepth           =  
       bpp                = 4   
       compression        = zlib
       title              =  
       no_url_info        = 0
       copyprevention_bit = 0
       backup_bit         = 0
       launchable_bit     = 0
     </template>
[download]

Now let's see if it passes the litmus test of wrapping extremely long lines onto the next line. This template is in the body of an email message, limited by the wrapping capabilities of the MUA. I had this figured out in my original code as follows:

     my $line="";
     my @unwrappeddata;
     foreach (@body) {
             chomp $_;
             next if /^#/;
        
             if (m/^[^\s=]+\s+=\s*/ || m/^\[.*\]$/) {
                     $line =~ s/^#/\n#/m;  
                     $line .= "\n";
                     push @unwrappeddata, $line;
                     $line = $_;
             } else {
                     $line .= $_;
             }
     last if qw/</template>/; 
     }
     $line .= "\n";
     push @unwrappeddata, $line;
[download]

I'll keep marching along, this is working out well so far.

Here comes another module suggestion then. :^) Have a look at Text::Wrap.

Makeshifts last the longest.