Template::Toolkit: better way to generate variable names?

[geektron]

i've found myself with a touch of a 'hack' in some templates i put together w/ Template::Toolkit. it works fine and all, but there has to be a better way to do this.

what i need to do:

1. loop X number of times ( in this case  x = 5 )
2. append X to the variable names ( to distinguish them )
3. use those names in a CGI form-method

my TT code looks like this:

    [% FOREACH s = [ 1 .. 5 ] %]

        [% PNAME = [ 'floorplan_name', s ] %]
        [% useName = PNAME.join('') %]
     ### other variables snipped for clarity.  
     ### there are 4 or so more just like this

     <tr>
        <td> Floor Plan Name </td>
        <td colspan='3'> 
        [% mycgi.textfield( '-name' => useName, 
                            '-size' => '50',
                            '-default' =>  THIS_PAGE.$IDX.floorplan_na
+me ) %] 
     </td>
     </tr>

etc.

i read through some of the mailing lists, and from what i saw, the  $var trick within TT only works for hash/ arrray keys, not for strings.

so, is there a better way?

sometimes, cases like this, i miss having a *real* job ... but not often. :-)

[davorg]

from what i saw, the $var trick within TT only works for hash/ arrray keys, not for strings.

Did you try it? The examples in the docs for the SET directive would seem to imply that you're wrong :)

[% useName = "floorplan_name$s" %]

--
<http://www.dave.org.uk>

"The first rule of Perl club is you do not talk about Perl club."
-- Chip Salzenberg

[geektron]

i think that's the only combination i *didn't* try.

the last one i tried was in the cgi.textfield method. something like:

[% mycgi.textfield( '-name' => "floorplan_name${s}" ... ) %]

and that gave me a template exception.

[larsen]

Did you try this?

[%
    foo_1 = 'value1'
    foo_2 = 'value2'
    foo_3 = 'value3'
    foo_4 = 'value4'
    foo_5 = 'value5'
%]
[% FOREACH n = [ 1 .. 5 ] %]
    [% 'foo_' _ n %] is [% ${ "foo_$n" } %]
[% END %]

Anyway, apply here the usual arguments against variable variable names. Use a hash or an array, if you can.

Update: I misread the question. See geektron's reply.

[geektron]

i really don't need a hash or array in this case.

if it were straight perl, i would have done:

foreach my $counterVar ( 1 .. 5 ) {
   $foo = "string" . $counterVar;
}

the issue was with the TT meta-language, really. it *can* get a bit odd...

what i *do* need out of the suggestion is:

   [% SET FOO = 'string' _$n %]

-- i do need to double-check the underscore location ... --

after reading the previous reply, the connection between TT's meta-language and 'core perl' kicked in.

[geektron]

[% 'foo_' _ n %]

this is exactly what i needed. many thanks.

[clscott]

If you create 5 copies of a form element with the same name CGI.pm will return the contents of all occurances of the
that fieldname as an array of the values in the order they were specified.

Update
MidLifeXis has a valid point concerning the order in which the values will be returned. So if the numbers are necessary to specify some type of ordering or precedence go with this revelation

This will simplify your code immensely when you need to drop back to 3 floor plans or increase to 7 floor plans.

In your template:

[% FOREACH s = [ 1 .. 5 ] %]
<tr>
        <td> Floor Plan Name </td>
        <td colspan='3'> 
        [% mycgi.textfield( '-name' => floorplan_name, 
                            '-size' => '50',
                            '-default' =>  THIS_PAGE.$IDX.floorplan_na
+me ) %] 
     </td>
</tr>

[% END %]

In your form processing cgi:

my $q = CGI->new;

my @floorplans = $CGI->param('floorplan_name');

# How many plans arrived?
my $num_plans = @floorplans;

# Looping over my plans
foreach my $plan ( @floorplans )
{
   &do_the_plan( $plan )
}

--
Clayton aka "Tex"

[MidLifeXis]

However (from my CGI.pm),

NOTE: As of version 1.5, the array of parameter names returned will be in the same order as they were submitted by the browser. Usually this order is the same as the order in which the parameters are defined in the form (however, this isn't part of the spec, and so isn't guaranteed).

I don't think you can rely 100% on this behaviour, especially if you are going to submit foo_1, bar_1, foo_2, bar_2, etc.

[geektron]

I don't think you can rely 100% on this behaviour, especially if you are going to submit foo_1, bar_1, foo_2, bar_2, etc.

that's pretty much my point in appending the indicator numbers. i don't want to depend too much on side-effects. the usually part of the perldoc is what bothers me. i need always, not usually

plus, there are about 7 other variables which go along with the set. so ... i need to remain defensive about data integrity.