Hi Jonathan,
I think the exampe of:
@loop = (
...
{value_set => 2, count_distribution => 1, sum_of_counts => 36 },
...
)
is invalid, since you never generate the loop contruct like that. Usually you
would do something like:
for ($min..$max) { # - loop through to max rows
push @loop, { # \
value_set => $_, # - make row values
count_distribution => make_value($_), # /
};
}
$ht->param(some_loop => [EMAIL PROTECTED]); # - make rows available
$ht->param(sum_of_counts => 36); # - make max count available
The point being that usually you build up loop content dynamicaly, say from a
database or a computation, rather than simply outputting static content.
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.
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.
That said, there may be a very slight increase in performance when output'ing
as you are no longer dealing with associative arrays.
Mathew
PS. In all of my templates, I know of exactly _zero_ cases where I could use
un-named loop variables.
Jonathan Lang wrote:
Requiring that all loops be handled by iterating through lists of
hashes leads to a lot of extra work on the script writer's end, and
results in the template writer having rather inflexible data to work
with. I'd like to propose a more flexible alternative, which ought to
be usable in addition to the current approach:
Allow the script writer to pass ordinary lists to a template.
Allow the template writer to access them using a modified version of
<TMPL_LOOP>:
<TMPL_LOOP> <!-- that's right; no loop control variable is given. -->
<TMPL_VAR list1> <!-- list1 is an ordinary list that got passed to
the template. -->
<TMPL_VAR list2> <!-- list2 is another such list. -->
</TMPL_LOOP>
This loop construct would display the first elements of list1 and
list2 on its first pass, the second elements of each list on its
second pass, and so on until it exhausts one of the lists (at which
point it stops).
Without a loop control variable, any variable could be used within the
loop, not just list-like variables. So you could do something like:
<ul>
<TMPL_LOOP>
<li><TMPL_VAR value_set>: <TMPL_VAR count_distribution> out of
<TMPL_VAR sum_of_counts></li>
</TMPL_LOOP>
</ul>
Given:
@value_set = (2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12);
@count_distribution = (1, 2, 3, 4, 5, 6, 5, 4, 3, 2, 1);
$sum_of_counts = 36;
This would produce:
<ul>
<li>2: 1 out of 36</li>
<li>3: 2 out of 36</li>
<li>4: 3 out of 36</li>
<li>5: 4 out of 36</li>
<li>6: 5 out of 36</li>
<li>7: 6 out of 36</li>
<li>8: 5 out of 36</li>
<li>9: 4 out of 36</li>
<li>10: 3 out of 36</li>
<li>11: 2 out of 36</li>
<li>12: 1 out of 36</li>
</ul>
The only restriction would be that ordinary lists can only be used
within a TMPL_LOOP.
To me, this seems a lot more intuitive (on both ends of the design)
than the current approach, where the script writer would have to say
something like:
@loop = (
{value_set => 2, count_distribution => 1, sum_of_counts => 36 },
{value_set => 3, count_distribution => 2, sum_of_counts => 36 },
{value_set => 4, count_distribution => 3, sum_of_counts => 36 },
{value_set => 5, count_distribution => 4, sum_of_counts => 36 },
{value_set => 6, count_distribution => 5, sum_of_counts => 36 },
{value_set => 7, count_distribution => 6, sum_of_counts => 36 },
{value_set => 8, count_distribution => 5, sum_of_counts => 36 },
{value_set => 9, count_distribution => 4, sum_of_counts => 36 },
{value_set => 10, count_distribution => 3, sum_of_counts => 36 },
{value_set => 11, count_distribution => 2, sum_of_counts => 36 },
{value_set => 12, count_distribution => 1, sum_of_counts => 36 },
)
Bulky and painful.
-
You might even have it handle lists of lists, by nesting TMPL_LOOPs:
<table>
<TMPL_LOOP>
<tr><TMPL_LOOP><td><TMPL_VAR count></td></TMPL_LOOP></tr>
</TMPL_LOOP>
</table>
and
@count = ([2, 3, 4, 5, 6, 7],
[3, 4, 5, 6, 7, 8],
[4, 5, 6, 7, 8, 9],
[5, 6, 7, 8, 9, 10],
[6, 7, 8, 9, 10, 11],
[7, 8, 9, 10, 11, 12]);
produces:
<table>
<tr><td>2</td><td>3</td><td>4</td><td>5</td><td>6</td><td>7</td></tr>
<tr><td>3</td><td>4</td><td>5</td><td>6</td><td>7</td><td>8</td></tr>
<tr><td>4</td><td>5</td><td>6</td><td>7</td><td>8</td><td>9</td></tr>
<tr><td>5</td><td>6</td><td>7</td><td>8</td><td>9</td><td>10</td></tr>
<tr><td>6</td><td>7</td><td>8</td><td>9</td><td>10</td><td>11</td></tr>
<tr><td>7</td><td>8</td><td>9</td><td>10</td><td>11</td><td>12</td></tr>
</table>
lists of lists of lists would also be possible, but the usefulness of
lists of lists is already getting close to marginal.
-
I have an idea that would allow script writers to load hashes into a
template as well; but IMHO that's not nearly as useful as loading
ordinary list variables.
--
Jonathan "Dataweaver" Lang
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Html-template-users mailing list
Html-template-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/html-template-users
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Html-template-users mailing list
Html-template-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/html-template-users
