v2.0.0 Target Acquisition

[pvande]

The list of issues we want to address in v2.0.0 is as follows:

• Adding Pragmas
  • Change Delimiter Pragma
• Removing the Change Delimiter tag
• Layout Facilities (several proposals)
• Comment Changes (allow commented tags)
• Lookup Changes (anchored lookups, "skips")
• Conditional Else
• Order Independence
• Language-agnostic Lambda tests
• Standardized Errors

This list is malleable at this point; comment now if you have additional targets you'd like considered.

[janl]

• Helpers
  (in the handlebars kind of sense, as per http://writing.jan.io/mustache-2.0.html (rough code for .js: janl/mustache.js@master...helpers))
• Addressing Contexts
  (also as per http://writing.jan.io/mustache-2.0.html — Not sure if "Lookup Changes" covers that)

[pvande]

Addressing Contexts (at least as described in the strawman) has been addressed by the spec since v1.0.0.

{
  "foo": {
    "bar": {
      "baz": 1,
      "gruff": "foo.bar.gruff"
    },
    "qux": 2,
    "gruff": "foo.gruff"
  },
  "baz": "baz",
  "gruff": "gruff"
}

# This works today!
{{#foo}}
  {{#bar}}  # <-- foo.bar
    {{baz}} # <-- foo.bar.baz
    {{qux}} # <-- foo.qux 
  {{/bar}}
{{/foo}}

The Lookup Changes target is actually a couple of other things. Firstly, it's about providing a way to get the behavior described in the strawman.

# "Anchors" find things specifically on the top of the context stack.
{{#foo}}
  {{#bar}}   # <-- foo.bar
    {{baz}}  # <-- foo.bar.baz
    {{@qux}} # <-- foo.bar.qux
  {{/bar}}
{{/foo}}

Secondly, it's about providing a mechanism for accessing keys not currently topmost on the context stack.

# "Skips" step over a value on the context stack.
{{#foo}}
  {{#bar}}      # <-- foo.bar
    {{gruff}}   # <-- foo.bar.gruff
    {{gruff'}}  # <-- foo.gruff
    {{gruff''}} # <-- gruff
    {{baz}}     # <-- foo.bar.baz
    {{baz'}}    # <-- baz
  {{/bar}}
{{/foo}}

Neither of these things is certain (especially the syntax), and both of them are controversial, since they introduce annotations to the name of the thing being looked up, rather than only to the tags.

---

As for Helpers, I'm nearly convinced. I've been stuck trying to understand whether the best solution is to just bite the bullet and implement filter chains, or whether adding data lookup from methods and lambdas would be an adequate solution. Any convincing you can lend me would be appreciated.

[groue]

It looks, @pvande, that the v2.0.0 tag lists all targeted points. Don't you think each point should have its issue? There's only three v2.0.0 issues right now.

Also, issue #38 "Proposal: template inheritance" is quite linked to the issue #49 "Proposal: dynamic partials". Should it be tagged v2.0.0 as well, or explicitly closed and linked to the "canonical" template-relationship issue #49 ?

[groue]

There is a new topic that I would like to be added to the v2.0.0 target:

• friendliness to developers (Mustache library users)
• friendliness to template writers (people who write templates)

Those are often the same people, but not always. For instance, a template writer could only have HTML skills.

In order for this "friendliness" to be achieved, I propose that a few major common use cases should be described for each kind of user, and explicitely added to the v2.0.0 target. There should NOT have Mustache explicit support for each of those use cases. But there should be the ability to implement them in a rather straightforward way.

The various proposals for each v2.0.0 targetted points would be criticized against those use cases, so that the most "friendly" would pop out and be eventually chosen.

For instance, on the developer-side: assuming Mustache still strives to be have a wide language support, there should be no assumption about the hosting language such as support for closures, meta-programming, duck-typing, or runtime introspection features of any kind. If a developer use-case needs such a language feature in order to be easy to implement, we'd have a spec failure.

On the template-writer side: Mustache templates are written and read by humans, not machines. If Mustache spec would introduce changes that makes harder to read, understand, edit, memorize Mustache constructs, then we would have a failure as well. Put in other words: Mustache should not become XML. Also, if the mustache spec assumes too much insight in the developer tasks, the spec would also fail from the template writer point of view. This should prevent any syntactic explosion, for instance.

On both sides: widely adopted representation of concepts should have the same representation in Mustache. I target you, @root and granddaddy'' constructs, when /root and ../../daddy are there for such a long time, with no flaw I know that any new syntax I've seen would "cure".

If those ideas seem legit to you, here are a few use cases that I'm sure all Mustache implementors have been asked by their users (I, as GRMustache developer, have surely been):

• ability to render 0-based loop indexes
• ability to render 1-based loop indexes
• ability to render something at the first item of a loop
• ability to render something at the last item of a loop
• ability to distinguish even and odd loop items
• ability to format numbers or dates
• prevention of "view-model bloat"
• ability to embed a template in a layout
• ability to debug templates (parsing)
• ability to debug templates (runtime)

It may look that some of these use-cases are already covered by the main v2.0.0 targetted points, that they are less general, that they are less interesting. I propose that they should not be seen that way: instead, each of those use cases, if we agree on their individual importance, should help criticizing the more general, more powerful constructs, so that we make sure simple tasks are simply done, and that power features do not make things harder for simple cases.

It's all about UX, developer-UX, and template-writer UX. Recommended reading : The Obvious, the Easy, and the Possible

[groue]

On the same "developer-UX" topic, it may be a good idea to ask each known Mustache implementor how their implementation deviates from the v1 spec, and which features were added on top of the plain Mustache.

This should reveal more common use cases, and it may also reveal flaws in the v1 of the spec, that the v2 could address.

For instance, GRMustache:

• does not honor white-space rules of the v1, and nobody cares (no issues on that topic since the introduction of the library two years ago)
• renders the raw output of lambdas, without parsing them, because of a bug in the spec regarding the relationship between lambdas and delimiters. This doesn't prevent users to acheive the spec behavior; but the spec behavior is not the default.
• introduces a few callbacks in order to avoid the "view-model bloat" and implement features that lambdas can not address (formatting and loop indexes for instance).
• supports {{ .name }} contruct in order to fetch the name key from the current context, avoiding looking for it in the stack.

[MattCheely]

@pvande I was going to save this for detailed discussion later, but since you said you're almost convinced, I'll comment here. I'm not a fan of helpers or other features that allow for passing model data to a method from within template. I've also yet to see a compelling use case.