Comment #1 on issue 34 by tim.schaub: Repeated section should iterate over
dictionaries and have special variables $name and $value
http://code.google.com/p/json-template/issues/detail?id=34
Data:
{"dict": {"key1": "value1", "key2": "value2"}}
Template with your proposal:
{.section dict}
<dl>
{.repeated section @}
<dt> {$name} </dt><dd> {$value} </dd><!-- what is @ here? -->
{.end}
</dl>
{.end}
Template with my proposal [1]:
{.section dict}
<dl>
{.repeated key @}
<dt> {key} </dt><dd> {...@} </dd><!-- @ is same for object and array -->
{.end}
</dl>
{.end}
With my proposal, you'd also dispense with the $index variable required for
array
iteration. Instead, the template designer would choose the name (e.g.
{.repeated
index list}).
And for iterating over elements in arrays and members in an object (in JSON
terms,
they are referred to as objects, not dictionaries) you'd get the same
pattern. The
cursor assumes the value of the element in an array or the member in an
object. The
(optional) name used after the .repeated declaration assumes the index in
an array
and the name of the member.
This aligns with what people might expect from other languages (for key in
obj). It
also dispenses with the extraneous "section" term in ".repeated section".
Finally,
if you really want to be concise and you don't need a reference to the
array index or
member name in your template, you could not include a named argument in your
.repeated declaration.
E.g. for an array
<ul>
{.repeated array}
<li> {...@} </li> <!-- cursor assumes value of element in array -->
{.end}
</ul>
E.g. for an object
<ul>
{.repeated object}
<li> {...@} </li> <!-- cursor assumes value of member in object -->
{.end}
</ul>
All this (my alternate proposal) also allows any names to be used in the
data
provided to the template ("$index", "$name", "$value", etc. are all free -
and
perfectly valid in JSON). I don't think it is necessary to reserve terms
like those.
A number of your responses to similar inquiries are along the lines of "the
application should munge the data to fit my template language." I think
this is a
somewhat unnecessary constraint. The template language could be made
simpler and
work with data that is less specific to this language alone. Template
designers who
don't control all aspects of the application would be happier. And
application
developers who don't care squat about the constraints or limitations of the
template
language would need to do fewer transforms on the data they pass along.
[1]
http://groups.google.com/group/json-template/browse_thread/thread/e83c2a0af5396da7
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "JSON
Template" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/json-template?hl=en
-~----------~----~----~----~------~----~------~--~---
