iterate over object members

[Tim Schaub]

Hey-

I've looked over recent threads on this list, but haven't seen this
covered. Please redirect me if it has been discussed before.

I'd like to be able to use the "repeated" directive to iterate over
object members (in JSON terms).

It seems to me like you force duplication of data if you only allow
iteration over array elements.

For example, if I wanted to have a template that both created a list of
links:

{.section pages)
Menu:
<ul>
{.repeated section @}
<li><a href="{@.url}">@.title</a></li>
{.end}
</ul>
{.end}

and had inline links to specific pages:

Link to page <a href="{page0.url}">{page0.title}</a>.

I would have to create a "data dictionary" that looked something like
the following:

{
"pages": [{
"title": "zero",
"url": "foo"
}, {
"title": "one",
"url": "bar"
}],
"page0": {
"title": "zero",
"url": "foo"
},
"page1": {
"title": "one",
"url": "bar"
}
}

Alternatively, if the template language allowed for iteration over
object members (and allowed for named repeat variables), then my menu
would look something like:

{.section pages}
Menu:
<ul>
{.repeated title @}
<li><a href="@.url">{title}</a>
{.end}
</ul>
{.end}

and my inline link would look like:

Link to page <a href="page.zero.url">zero</a>.

Most importantly, my "data dictionary" would collapse to simply:

{
"pages": {
"zero": {"url": "foo"},
"one": {"url": "bar"}
}
}

If this is something that is not already handled in a different way, I
think it could be implemented in a mostly backwards compatible way
(breaking where templates use substitution for a variable named "section").

If this email doesn't make any sense, I could rephrase it by starting
with the collapsed data dictionary and asking "how can I create a list
of links from this (and allow for deep linking without data duplication)?"

Thanks,
Tim

[Tim Schaub]

Tim Schaub wrote:

... snip ...

>
> and my inline link would look like:
>
> Link to page <a href="page.zero.url">zero</a>.
>

Ignore the typos, that should be

Link to page <a href="{pages.zero.url}">zero</a>

of course.

[Andy Chu]

Hey, thanks for the suggestion. This has crossed my mind, but so far
no one else has brought it up. How about giving the keys and values
special names, e.g. treat it as a 2 element object with "name" and
"value" fields, like:

List:
{.repeated section pages}
{name} {value.url}
{.end}

Page 0 URL: {page0.url}

-->

List:
zero foo
one bar

Page 0 Url: bar

It would have to work with nested dictionaries too.

> If this is something that is not already handled in a different way, I
> think it could be implemented in a mostly backwards compatible way
> (breaking where templates use substitution for a variable named "section").
>
> If this email doesn't make any sense, I could rephrase it by starting
> with the collapsed data dictionary and asking "how can I create a list
> of links from this (and allow for deep linking without data duplication)?"

It make sense, and can be done without breaking compatibility, since
repeated sections only take lists now.

But in general, JSON Template can't handle arbitrary JSON. It's
supposed to be JSON you craft for the template specifically.

For example, it doesn't handle JSON where a: 1 or a: [1, 2] -- the
JSON has to be transformed so the value is always a list.

To do this within the existing system, I would write a function that
annotates the data dictionary. Say you get a bunch of rows of URLs
from a database.

rows:

(zero, foo)
(one, bar)

Now I would write a function to turn that into JSON:

{
pages-list: [{

"title": "zero",
"url": "foo"
}, {
"title": "one",
"url": "bar"
}],

"zero": "foo",
"one": "bar"
}

So to play devil's advocate, there's no real duplication there. It's
just some transformations in the code, which you always need anyway.
I think I would have to see an actual example of this. Is it
something you really ran into?

Andy

[Tim Schaub]

Andy Chu wrote:
> Hey, thanks for the suggestion. This has crossed my mind, but so far
> no one else has brought it up. How about giving the keys and values
> special names, e.g. treat it as a 2 element object with "name" and
> "value" fields, like:
>

It seems like this could be done without adding more reserved words to
the language.

.repeated user_chosen_1 user_chosen_2

Then user_chosen_1 becomes the name of each member (in user_chosen_2)
and the cursor (@) assumes the value for each member.

As suggested in ticket 13 [1], one of 'repeated' or 'section' could go
in '.repeated section'. My suggestion would be to give some meaning to
'section' and to keep 'repeated'.

Data dictionaries already can't use members named 'length' with a value
of 0 (in the js implementation [2]). I think it would be unfortunate to
take the names 'name' and 'value' as well.

Tim

[1] http://code.google.com/p/json-template/issues/detail?id=13
[2] I'll create a ticket for this.

--
Tim Schaub
OpenGeo - http://opengeo.org
Expert service straight from the developers.

[Andy Chu]

On Mon, Sep 7, 2009 at 9:09 AM, Tim Schaub<tsc...@opengeo.org> wrote:
>
> Andy Chu wrote:
>> Hey, thanks for the suggestion.  This has crossed my mind, but so far
>> no one else has brought it up.  How about giving the keys and values
>> special names, e.g. treat it as a 2 element object with "name" and
>> "value" fields, like:
>>
>
> It seems like this could be done without adding more reserved words to
> the language.

The thing I suggested won't cause any name conflicts. Any data
dictionary with keys called "name" and "value" will still be
formattable.

Although I think they should be made more special-looking, possibly
$name and $value, or @name and @value.

> .repeated user_chosen_1 user_chosen_2
>
> Then user_chosen_1 becomes the name of each member (in user_chosen_2)
> and the cursor (@) assumes the value for each member.

I don't really see a reason for this extra flexibility. It doesn't
read that intuitively either.

> As suggested in ticket 13 [1], one of 'repeated' or 'section' could go
> in '.repeated section'.  My suggestion would be to give some meaning to
> 'section' and to keep 'repeated'.

That's not quite the suggestion -- it just allows {.section } to
format lists. {.repeated foo} wouldn't be allowed, it's still
{.repeated section foo}.

But I'm still not convinced about the whole thing. What situation do
you need this in? I think for now it would be fine to file an issue
and if someone else brings it up, the details can be worked out. But
in general there should be many use cases for a new language feature.

Andy

[Andy Chu]

FYI I became convinced by a few use cases:

http://code.google.com/p/json-template/issues/detail?id=34

I implemented $index for lists and repeated sections. So my proposal
is to implement $name and $value.

So {"foo": [1,2,3], "bar": false} implicitly gets turned into:

[ {"$name": "foo", "$value": [1,2,3]},
{"$name": "bar", "$value": False},
]

Comments welcome.

Andy

On Mon, Sep 7, 2009 at 9:09 AM, Tim Schaub <tsc...@opengeo.org> wrote:
>