Feature: moar dot notation hotness

[bobthecow]

1. Given that {{ . }} resolves as the current top of the context stack;
2. And when any falsey segment in a dotted name is encountered, the whole name yields '';
3. A name like {{ .name }} should imply {{ [current scope].name }};
4. Thus, it must resolve as truthy only if a member of the current scope matches name.

This is a one-liner to implement in Mustache.php, and seems completely in line with current spec, so I'm considering adding it. Can we get this into spec v1.2?

c.f. https://github.com/bobthecow/mustache.php/issues/98

[bobthecow]

diff --git a/specs/interpolation.yml b/specs/interpolation.yml
index 2237b55..acae566 100644
--- a/specs/interpolation.yml
+++ b/specs/interpolation.yml
@@ -171,6 +171,15 @@ tests:
     template: '"{{#a}}{{b.c.d.e.name}}{{/a}}" == "Phil"'
     expected: '"Phil" == "Phil"'

+  - name: Dotted Names - Leading Dot
+    desc: A leading dot should force resolution inside the current scope.
+    data:
+      a: { }
+      b: { name: 'Name' }
+      name: 'Fail'
+    template: '{{#a}}{{.name}}{{/a}}{{#b}}{{.name}}{{/b}}'
+    expected: 'Name'
+
   # Whitespace Sensitivity

   - name: Interpolation - Surrounding Whitespace

[pvande]

s/current scope/top of stack/g;

This is something currently being discussed for v2.0.0. I'm not entirely sold on the notion of . having two distinct meanings in a key based on context, but the alternative would be to introduce another sigil, which has problems of its own ({{ @name }} has a nice Ruby or CoffeeScript-like instance member feel to it -- and was CoffeeScript's shorthand for this.name -- but attaching sigils to keys is something we've thusfar avoided).

I'll keep thinking on it. Thanks @bobthecow!

[bobthecow]

Yeah, I went back and forth between "top of stack", "current scope" and "section context" a few times. Apparently I didn't even manage to settle completely on one :)

In this case, I feel it's consistent; the dot is already being used for both meanings ("top of stack" and "child traversal"). We're just providing a mechanism for combining both types of usage in the same tag.

[devinrhode2]

I'm confused on what the difference would be between{{.name}}and{{name}} - could you show an example of how this idea would work differently?

[groue]

@devinrhode2 Look at the test supplied by @bobthecow: {{#a}}{{.name}}{{/a}} does not output anything, when {{#a}}{{name}}{{/a}} would have been rendered as "Fail". This is because {{.name}} looks for the key in the top context object (and a does not provide the name key), when {{name}} performs a full lookup, which starts at the top context object, but keeps on looking in the enclosing contexts (until it finds name in the root object).

This lookup mechanism is based on what is called the "context stack". The context stack stars with the rendered data, extends each time a section is entered, and shrinks each time a section is left. Not all Mustache implementations provide this feature, this may explain your question is the first place.

[bobthecow]

@devinrhode2 The Mustache.php wiki has a page on variable resolution that explains the context stack a bit. Plus what @groue said :)

[groue]

@bobthecow : it's interesting how your documentation of the context stack, and GRMustache's one (at https://github.com/groue/GRMustache/blob/master/Guides/runtime/context_stack.md) do not avoid talking about implementation details (especially for the definition of a missing key). It may actually be very difficult to write a generic context stack documentation :-)

[bobthecow]

@groue The intention of my documentation wasn't to provide a general purpose overview of the context stack, it was to explain how variables are resolved in mustache.php :)

I think it's possible to explain... Unfortunately, there isn't a really good language-agnostic explanation of the mustache context stack anywhere, so I keep linking people to the variable resolution page.

[bobthecow]

Also, I didn't notice that you'd implemented this spec PR in GRMustache already. Awesome.

[devinrhode2]

Got it now, thanks to Bob's docs and the test description "A leading dot should force resolution inside the current scope."

I think is a useful feature that makes sense without any radical new syntax, this should go in the spec.

[groue]

@bobthecow Yes, we implementors have to implement the missing features when the spec falls short. Especially considering it hasn't evolved since March 2011.

[jonahkagan]

This was exactly what I needed!

For anyone interested, I've implemented the leading dot extension in a fork of Milk here: https://github.com/jonahkagan/Milk. I've verified it against @bobthecow's addition to the spec.

@pvande, I doubt you want to add this to the main repo, but if you do let me know and I can submit a PR.

[BigBlueHat]

+1 for getting anchored dot notation into the mustache spec. It's an intuitive key existence check syntax that's very useful when using trees of data and nested partials. Without it, the solution requires littering the View to make up for the lack of this (or something similar).

@bobthecow keep up the greatness!

[tomek-he-him]

Bump! That’s a very useful feature – see https://github.com/mustache/spec/pull/92#issue-104010862.

[aubelsb2]

This is what I tried (failed) and need.

[jgonggrijp]

I reopened #92. Please continue discussion about the proposal over there, or discuss stack masking in general in #154.