Is there a way to cope with this elegantly?
Preprocess the data you send to the template system to form that the template system can understand.
| [reply] |
| [reply] |
If you template snippet would work, the data input for it would look like
$tmpl->param(loopname => [
{
anothervariable => 'foo',
foo => 'actual value',
},
...
])
You need to change that to
$tmpl->param(loopname => [
{
fixed_key => 'actual value',
},
...
])
For example by creating a fixed coyp of each hashref like this:
my $new = { fixed_key => $old->{$old->{anothervariable}} };
| [reply]
[d/l]
[select] |
One way that I found to do something like this (in the context of Template::Toolkit, as it so happens) is through the idea of closures.
In other words, within the Perl sub that prepares my screen for display, I set up various statements like my $closure = sub { ... }, thus creating code-references. I pass those variables to the template. This templating system knows that, when a particular variable’s value is a code-ref, it’s supposed to call that routine and use its result. (I have no reason to believe that the templating system you’re using won’t be similar.) Hence, the calls occur, and since the closures are defined within an outer sub, they have access to all of the local (my) variables within it. They are, then, “part of” that subroutine, but they are called by the template as it is doing its work.
There is always a delicate balance between what logic you want to put into a template-file and what logic you want to put into the application. This strategy has allowed me to, in a way, have some of the best of both worlds. (And it is heavily documented in both sets of files.) The template avoids cross-dependency regarding how the data is being stored, because it has access to a simple function that gives it the right answer. If I have to change that answer or how it is derived, I only must change it in one place.
| |
Can you use a small example to illustrate?
| [reply] |