Really? And there was me thinking I was knocking up a quick proof-of-concept script. Still, I learnt a few things along the way, which is why I try to answer almost all the questions posted here in the first place. I only post the results if I *think* I have something that might be useful.

Re: Config::Inifiles. As hacker stated, he has been using that module, but going by the code he posted, it seems as though the keys parsed get supplied back to the caller as individual variables (eg. $bpp = 4 ) rather than as a collection? This would appear to be the main cause of hacker's coding troubles. It's much easier to avoid the

if(exists key) { 
  if defined key) { 
    if value supplied { 
      if(value is valid) { 
         if(value eq this) { 
            use this 
         } 
         elsif (value eq that) { 
            do that 
         } else { 
            yell
         } 
      } 
      else { 
         use default 
      }
   } 
   else if( value is required ) {
      do something
   }
   else
      do something else
   }
}
else {
   key not supplied...
}
[download]

for every key, if they are in a collection.

Note:I haven't looked at the modules you mention, I'm just going by what I see.

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.