samwyse
commented
11 years ago Here is bobthecow's example from https://github.com/bobthecow/mustache.php/pull/130, reimplemented using a mutable context object. First, the layout.
<!-- layout.mustache -->
<!DOCTYPE html>
<html>
<head>
<title>{{ title }}{{^ title }}My Alsome Site{{/ title }}</title>
{{ stylesheets }}{{^ stylesheets }}
<link rel="stylesheet" href="/assets/css/default.css">
{{/ stylesheets }}
</head>
<body>
<header>
{{ header }}{{^ header }}
<h1>Welcome to My Alsome Site</h1>
{{/ header }}
</header>
<section id="content">
{{ content }}{{^ content }}
<p>Hello, World!</p>
{{/ content }}
</section>
{{ scripts }}{{^ scripts }}
<script src="/assets/js/default.js"></script>
{{/ scripts }}
</body>
</html>Next, the input template.
<!-- page.mustache -->
{{< layout.mustache }}
{{$ title }}My Alsome Page{{/ title }}
{{$ stylesheets }}
<link rel="stylesheet" href="/assets/css/page.css">
{{/ stylesheets }}
{{$ header }}
<h1>My page has some items!</h1>
{{/ header }}
{{$ content }}
<ul>
{{# items }}
<li><a href="{{ link }}" title="{{ name }}">{{ name }}</a></li>
{{/ items }}
</ul>
{{/ content }}
{{/ layout.mustache }}The only problem with doing it like this is that it would result in four blank lines before the "" line. The simplest solution would be to simply omit the blank lines from the template; another would be to change the page to use a special lambda that suppresses empty lines, i.e.
{{< layout.mustache }}{{# omit_empty_lines }}
....
{{/ omit_empty_lines }}{{< layout.mustache }}A few observations: All occurrences of "{{$ name }}default value{{/ name }}" in the template have been replaced by "{{ name }}{{^ name }}default value{{/ name }}". In Unix shells, this is called Substitution with a default value. MCO syntax is more verbose, but allows greater flexibility.
Substitution for actual value
{{# name }}substituted value{{/ name }}This allows an different substitution to be used if a value is set, for example, "{{# name }}The value of name is {{ name}}{{/ name }}{{^ name}}Name is unset.{{ name }}"
Substitution with a default assignment
{{^ name }}{{$ name }}default value{{/ name }}{{/ name }}{{ name }} This allows an undefined value to get a default that can then be used throughout the remainder of the template.
spullara
groue
jgonggrijp
I've just waded through issue 38: Template inheritance. I know I'm a couple of years late to that dance, but I suspect that one reason why the proposal hasn't been adopted is that there was never any consensus on what should be done; there were at least two implementations that behaved slightly differently. So rather than adding to an already lengthy thread, I'm going to propose something different that accomplished the same goal: Mutable context objects (MCO). (And I think that this will also satisfy the goals of issue 63: Inline partials.
MCOs use two "new-ish" bits of syntax.
While the mutable context object is on the stack, the rest of Mustache works the same as always.
The preceding renders as:
Note that using the same key overwrites the previous value.
The preceding renders as:
Note how this interacts with partials. Here is an example of a partial:
Now, let's see what happens when it is used like this:
You wind up with this:
Needless to say, you can push multiple MCOs onto the context stack; any new values are written to the most recently created MCO (and obviously disappear when it gets popped). Any objects added to the context stack after the MCO are considered immutable, and are skipped over when adding a value. Also, by the judicious use of {{#key}} and {{^key}} sections, you have complete control over how substitutions are performed.
BTW, I expect that the last example is going to be a common use case, so I'd suggest that the following should be interpreted as doing the same thing:
Finally, I know that all of this can be done via lambdas. I would note that (a) just because anything can be computed via a Turing machine doesn't mean that you should ignore other ways of doing it, and (b) lambdas are an optional part of the spec, so IMHO that isn't a good reason to reject this or any other proposal. Also, I'm fully aware that I'm re-using sigils that other implementations have used for years. Feel free to suggest others that I could use instead, but note that this spec could, like lambdas, be an optional part of the overall spec. Conflicting implementations could then ignore it, possibly later adding an option to their engine to toggle the interpretation.
Your thoughts?