Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Proposal: Limiting context when using implicit iterators #10

leth opened this Issue · 9 comments

5 participants


Given the following context:

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

The following:

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

Will output something like:

    123 - one
    abc - Hello World

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

    {{.data}} - {{}}{{.name}}{{/.name}}

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.

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

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.


Shameless plug, but the strawman for M2 addresses this:


@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.


@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.


@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?


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.

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

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

{{ }}
{{# }}{{ 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.


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


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



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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.