Proposal: Limiting context when using implicit iterators

[leth]

Given the following context:

{
    name: 'Hello World',
    list: [
        { data: '123', name: 'one' }
        { data: 'abc' }
    ]
}

The following:

{{#list}}
    {{data}} - {{#name}}{{name}}{{/name}}
{{/list}}

Will output something like:

    123 - one
    abc - Hello World

It might be nice if you could syntactically limit the context to the current iteration

{{#list}}
    {{.data}} - {{#.name}}{{.name}}{{/.name}}
{{/list}}

To get:

    123 - one
    abc - 

The use case I have is printing out html sytlesheet include fragments: the optional title attribute is missing, and it's finding the page title attribute up the context stack.

{{#stylesheets}}
    <link rel="stylesheet" href="{{href}}" type="text/css" {{#title}}title="{{title}}" {{/title}}charset="utf-8">
{{/stylesheets}}
....
<h1>{{title}}</h1>

[pvande]

Obviously, the advice commonly given for this problem is either "change the name of your page title attribute" or "normalize your stylesheet objects so that they share common keys" -- and while these are generally good guidelines, it isn't a particularly friendly answer for a relatively common case.

[janl]

Shameless plug, but the strawman for M2 addresses this: http://writing.jan.io/mustache-2.0.html

[leth]

@pvande thanks, I guess it's a matter of how common a use-case it is.

@janl Cool. I think it's definitely an issue, but I'm not sure what syntax would be best.

[pvande]

@leth Theoretically, template data is always entirely under your control and any issues like this have understood workarounds. In practice, that's just a dumb assumption.

There are actually two problems to solve here, and only one actually has a reasonable solution:

• How do I check the existence of a data member in only the topmost context?
• How do I check the existence of a data member in an arbitrary context?

The first problem would be simply solved if we had opted to use a character other than . for the implicit iterator -- in that case, you would be checking for {{# *.name }} (where * is the implicit iterator). The solution, then, may boil down to "change the implicit iterator", I don't know.

The second problem stems from the fact that we don't permit arbitrary context addressing. I tend to see this as more of a feature than a bug, but it does lead to some discomfort around key masking.

@janl I've created a new issue for discussing masked key resolution. See #11.

[leth]

@pvande That's a pretty good analysis of the problem :) Shall I close this issue, or are there things that aren't covered by #11?

[pvande]

Issue #11 is primarily focussed on discussing mechanisms for accessing masked data.

The problems described here are special cases of anchored lookups (which we have, implemented using dotted names); specifically that there is no reliable way of handling anchored lookups across iteration boundaries. The issue you raised is probably the most common instance of the problem, where you want a name (or convention) you can use to anchor the lookup to the top of stack.

The simple fix is to provide a construct that anchors lookups to the top of stack.

{{ @name }}
{{# @name }}{{ name }}{{/ @name }}

A more general fix is to give the top of stack an anchorable name.

{{ this.name }}
{{# this.name }}{{ name }}{{/ this.name }}

An even more general (and somewhat disjoint) fix is to provide a name for the current iteration element.

{{ :list.name }}
{{# :list.name }}{{ name }}{{/ :list.name }}

The advantage to this last case is that it permits an anchor for any section's current iteration (with a unique name). It's also arguably the hardest to implement.

tl;dr: There's still an issue here; let's not close this down just yet.

[cjerdonek]

/cc @cjerdonek (Is there a better way to subscribe to an issue?)

[leth]

There's a link to enable notifications just below the comment form :)

[sl1m3d]

Hello,

Just wanted to reping this issue. I had to implement work around for it today. I support(ed) the way leth proposed (even before seeing this issue).

Here's the link to the same issue i opened with GRMustache.
groue/GRMustache#19

[jgonggrijp]

This proposal was later duplicated in #52. It has a pull request in #92. Please continue discussion about the proposal over there, or discuss stack masking in general in #154.