Iterating 2 sibling lists in parallel in the same repeated section?

[Lucio]

Hi all,

I couldn't find any relevant threads about my question. Feel free to
redirect me if I missed something obvious.

Asking by example may be simpler. Say I have the following script:


#! /usr/bin/env python
import jsontemplate
tmpl = """
{.repeated section a}
{@}
{.end}
"""
result = jsontemplate.expand(tmpl, dict(
a = [1, 2, 3, 4],
b = list("abcd"),
))
print result

It produces this output:
1
2
3
4

Now I'd like to output the elements of 'a' and 'b' side by side, in
parallel, to produce something like:
1 a
2 b
3 b
4 d

Is there any way to achieve this at the template level (i.e., without
transforming my dict)?


I am looking for something in the lines of this hypothetical syntax:

{.repeated section a}
{@} {***@index}
{.end}

or:

{.repeated section a b}
{@.a} {@.b}
{.end}


Thanks!
--lucio

[Andy Chu]

Post by Lucio
Is there any way to achieve this at the template level (i.e., without
transforming my dict)?

There isn't a way of doing that unfortunately. I have seen some
similar questions and so far the answer is that JSON Template works
best when you craft your JSON for it. If there is some scheme that
will address all the concerns at once, without adding one-offs for
each case, I'm interested, but I can't think of anything.

Post by Lucio
{.repeated section a}
{.end}

This is sort of interesting, but I worry that it's not very general.
Like what if you want to iterate over a list of strings and a list of
objects in parallel? It gets a little confusing.

Post by Lucio
{.repeated section a b}
{.end}

I think this is being too loose with the meaning of the '.' operator.

Andy

[Lucio]

Thanks for answering Andy.

Post by Lucio
Is there any way to achieve this at the template level (i.e., without
transforming my dict)?

There isn't a way of doing that unfortunately.  I have seen some
similar questions and so far the answer is that JSON Template works
best when you craft your JSON for it.  If there is some scheme that
will address all the concerns at once, without adding one-offs for
each case, I'm interested, but I can't think of anything.

I see what you are saying. If you bear with me for a moment, I'd
lobby for some *template* mechanism that allows for parallel
iteration. While I agree with you that "adding one-offs for each
case" is definitely not the way to go (a.k.a. growing hairs :-), it
seems to me to be that parallel iteration is a pattern way too common
to be overlooked.

Consider my particular use case: rendering an html table. My
canonical JSON representation of the table is something like:
{
column_metadata: [
{name: "col1", class: "string", width: "30", ...},
{name: "col2", class: "number", width: "10", ...},
...
],
data: [
["value1", 100, ...],
["value2", 200, ...],
...
]
}

where the following assertion is true: columns_metadata.length ==
data[<n>].length

From both efficiency and programming effort standpoints, it'd be

highly desirable avoid transforming each cell in "data" into an object
that includes its column metadata.

Again, I agree with you in that there will always be the need for some
sort of transformation at the data model level. But I'd argue that
having template constructs that allow you traverse your *canonical*
data representation (or something as close to it as possible) is a big
plus and a step in the right direction.

Post by Lucio
{.repeated section a}
{.end}

This is sort of interesting, but I worry that it's not very general.
Like what if you want to iterate over a list of strings and a list of
objects in parallel?  It gets a little confusing.

Post by Lucio
{.repeated section a b}
{.end}

I think this is being too loose with the meaning of the '.' operator.

Actually the syntax above is *not* a proposal or something. It is
admittedly a quick and dirty notation to express what I wanted to
generate.

Andy

Keep up the good work and thanks for a great project.

--lucio

[Andy Chu]

Post by Lucio
Thanks for answering Andy.

Post by Lucio
Is there any way to achieve this at the template level (i.e., without
transforming my dict)?

There isn't a way of doing that unfortunately.  I have seen some
similar questions and so far the answer is that JSON Template works
best when you craft your JSON for it.  If there is some scheme that
will address all the concerns at once, without adding one-offs for
each case, I'm interested, but I can't think of anything.

I see what you are saying.  If you bear with me for a moment, I'd
lobby for some *template* mechanism that allows for parallel
iteration.  While I agree with you that "adding one-offs for each
case" is definitely not the way to go (a.k.a. growing hairs :-), it
seems to me to be that parallel iteration is a pattern way too common
to be overlooked.
Consider my particular use case:  rendering an html table.  My
{
 column_metadata: [
   {name: "col1", class: "string", width: "30", ...},
   {name: "col2", class: "number", width: "10", ...},
   ...
 ],
 data: [
   ["value1", 100, ...],
   ["value2", 200, ...],
   ...
 ]
}
where the following assertion is true:  columns_metadata.length ==
data[<n>].length
From both efficiency and programming effort standpoints, it'd be
highly desirable avoid transforming each cell in "data" into an object
that includes its column metadata.

Right, well even the data: [ ["value1", 1, ...], ["value2", 2, ...]
...] is not all that well supported. Usually I just put keys in front
of everything, which I suppose could be called bloated. But it's more
"self describing" and usable from JS code.

That's really your canonical representation? Where is it coming from?
You need to put the metadata next to *every* value? I'm not sure
what kind of output you're generating from that JSON.

Andy

[Lucio]

Post by Andy Chu

Post by Lucio
Thanks for answering Andy.

Post by Lucio
Is there any way to achieve this at the template level (i.e., without
transforming my dict)?

There isn't a way of doing that unfortunately.  I have seen some
similar questions and so far the answer is that JSON Template works
best when you craft your JSON for it.  If there is some scheme that
will address all the concerns at once, without adding one-offs for
each case, I'm interested, but I can't think of anything.

I see what you are saying.  If you bear with me for a moment, I'd
lobby for some *template* mechanism that allows for parallel
iteration.  While I agree with you that "adding one-offs for each
case" is definitely not the way to go (a.k.a. growing hairs :-), it
seems to me to be that parallel iteration is a pattern way too common
to be overlooked.
Consider my particular use case:  rendering an html table.  My
{
 column_metadata: [
   {name: "col1", class: "string", width: "30", ...},
   {name: "col2", class: "number", width: "10", ...},
   ...
 ],
 data: [
   ["value1", 100, ...],
   ["value2", 200, ...],
   ...
 ]
}
where the following assertion is true:  columns_metadata.length ==
data[<n>].length
From both efficiency and programming effort standpoints, it'd be
highly desirable avoid transforming each cell in "data" into an object
that includes its column metadata.

Right, well even the data: [ ["value1", 1, ...], ["value2", 2, ...]
...] is not all that well supported.  Usually I just put keys in front
of everything, which I suppose could be called bloated.  But it's more
"self describing" and usable from JS code.

I had no problems traversing the data matrix above using 2 nested
{.repeated section @} and {@}. I tested this in the javascript
implementation.

There's no question that explicit key usage is a superior format when
it comes to conveying semantics. But in my use case semantics are
obvious and saving bandwith could be relevant (think of an app that
supports heavy user pagination of tabular results sent as JSON).

Post by Andy Chu
That's really your canonical representation?  Where is it coming from?
 You need to put the metadata next to *every* value?  I'm not sure
what kind of output you're generating from that JSON.

s/canonical repr/my standard format to address the problem at hand/

Say I want to attach a class attribute to all cells in an html table
so that cells in the same column end up with the same class:

<table>
<tr>
<td class="string">value1</td>
<td class="number">100</td>
...
</tr>
<tr>
<td class="string">value2</td>
<td class="number">200</td>
...
</tr>
...
</table>

Unless some sort of parallel iteration is available, I guess I do need
metadata next to every value.

That's where leveraging the already available "@index" value to index
a separate list down the stack would open a lot of possibilities
(i.e., saving transformations in the pretty common case of data
structures containing parallel lists).

Post by Andy Chu
Andy

--lucio

[Andy Chu]

Post by Lucio
I had no problems traversing the data matrix above using 2 nested
implementation.
There's no question that explicit key usage is a superior format when
it comes to conveying semantics.  But in my use case semantics are
obvious and saving bandwith could be relevant (think of an app that
supports heavy user pagination of tabular results sent as JSON).

Well, one workaround is to send the JSON in your compact format, and
then on the client side it can be expanded. It should be like 5 or 10
lines just to annotate each entry of a list with one of the parent
values.

Post by Lucio

Post by Andy Chu
That's really your canonical representation?  Where is it coming from?
 You need to put the metadata next to *every* value?  I'm not sure
what kind of output you're generating from that JSON.

s/canonical repr/my standard format to address the problem at hand/
Say I want to attach a class attribute to all cells in an html table
<table>
 <tr>
   <td class="string">value1</td>
   <td class="number">100</td>
   ...
 </tr>
 <tr>
   <td class="string">value2</td>
   <td class="number">200</td>
   ...
 </tr>
 ...
</table>
Unless some sort of parallel iteration is available, I guess I do need
metadata next to every value.
a separate list down the stack would open a lot of possibilities
(i.e., saving transformations in the pretty common case of data
structures containing parallel lists).

I think I would need a more detailed proposal. The @index might work
in the simplest case, but I'm concerned that it will interact badly
with more complex use cases.

The semantics are mostly in the wiki, but it's not "strictly" defined.
The code is intentionally very simple to produce simple and
orthogonal semantics. Although I guess one case where it is already a
little ad hoc is "@". Like "@.@" or "@.foo" I don't think work very
well. I haven't really thought about if they should. ***@index is
similarly problematic.

Andy