Re: [htmltmpl] Alternate loops

[Jonathan L. <dat...@gm...>]

Mathew Robertson wrote:
> Hi Jonathan,
>
> I think the exampe of:
>
>  @loop =3D (
>    ...
>    {value_set =3D> 2, count_distribution =3D> 1, sum_of_counts =3D> 36 },
>    ...
>  )
>
> is invalid, since you never generate the loop contruct like that.

"invalid" may be too strong of a word; maybe you mean "unlikely"?

For brevity's sake, I was describing the contents of a variable that's
about to be loaded into the template; I was not intending to address
the question of how it gets put together in the first place.  That
said:

> Usually you would do something like:
>
>   for ($min..$max) {                        # - loop through to max rows
>     push @loop, {                           # \
>       value_set =3D> $_,                      # - make row values
>       count_distribution =3D> make_value($_), # /
>     };
>   }
>   $ht->param(some_loop =3D> \@loop);          # - make rows available
>   $ht->param(sum_of_counts =3D> 36);          # - make max count availabl=
e
>
> The point being that usually you build up loop content dynamicaly, say fr=
om a database
> or a computation, rather than simply outputting static content.

True, but not a point that has much of an impact on my proposal.

Take the example given in the documentation:

  my @words =3D qw(I Am Cool);
  my @numbers =3D qw(1 2 3);
  my @loop_data =3D ();
  while (@words and @numbers) {
    my %row_data;
    $row_data{WORD} =3D shift @words;
    $row_data{NUMBER} =3D shift @numbers;
    push (@loop_data, \%row_data);
  }
  $template->param(THIS_LOOP =3D> \@loop_data);

--

  <TMPL_LOOP NAME=3D"THIS_LOOP">
    Word: <TMPL_VAR NAME=3D"WORD"> <br>
    Number: <TMPL_VAR NAME=3D"NUMBER"> <p>
  </TMPL_LOOP>

Everything after the "my @numbers" line and before the
"$template->param" line is an example of having to jump through hoops
in order to get the information into a "table format" that H::T can
use.  Furthermore, the related template is under some severe
limitations, in that information that has not been put into @loop_data
cannot be displayed from inside a <TMPL_LOOP> tag.

Looking at the same example, but implementing my proposal, you'd have this:

  my @words =3D qw(I Am Cool);
  my @numbers =3D qw(1 2 3);
  $template->param(WORDS =3D> \@words);
  $template->param(NUMBERS =3D> \@numbers);

--

  <TMPL_LOOP>
    Word: <TMPL_VAR NAME=3D"WORDS"> <br>
    Number: <TMPL_VAR NAME=3D"NUMBERS"> <p>
  </TMPL_LOOP>

Much simpler, no?

> Also, I'm not confident that H::T could be extended with the
> list-of-list case (without some re-work), as H::T uses
> recursion for TMPL_LOOPS (eg: when a loop begins, a new
> instance of H::T is created -> it becomes the current context).
> Note that most of my templates use lists-of-lists to produce
> tables, so I do consider this to be a must have.

See, that "current context" bit is something else that I'd like to get
away from with unnamed template loops.  Going back to what you have in
the second quote above: if I use <TMPL_LOOP NAME=3D"some_loop">, I can
only use <TMPL_VAR NAME=3D"value_set"> and <TMPL_VAR
NAME=3D"count_distribution"> within it; I cannot use <TMPL_VAR
NAME=3D"sum_of_counts"> in there, because "sum_of_counts" isn't in the
current context.  Unnamed template loops wouldn't change the current
context, so I'd be able to make use of any or all of the appropriate
arrays or scalars within it.

> The idea of unnamed template loops is a interesting idea, but
> all it really does is to increase the complexity of H::T, for
> no real increase in useability.

I'll have to beg to differ.  As things stand, the script writer has to
have a strong feel for how the data that he provides is going to be
used, and needs to set up the lists of hashes accordingly.  The
template writer is then constrained to display each list-of-hashes in
a separate loop, even if he thinks that the data makes more sense
bundled together in a single loop.  And that's not even mentioning the
"current context" constraint.
With unnamed template loops, the template writer is free to bundle as
much or as little of the available data into a given loop as he feels
is appropriate.  If that's not a real increase in useability, what is?

> PS. In all of my templates, I know of exactly _zero_ cases where I could =
use un-named
> loop variables.

Correction: Every last case you know of _could_ use unnamed loops,
since unnamed loops can do everything that regular loops can.  Not one
of your cases _does_, obviously, since unnamed loops aren't currently
implemented; but that's not the same thing.  And I can think of a
number of cases where unnamed loops would streamline the script
writer's job without complicating the template writer's job.

--
Jonathan "Dataweaver" Lang