twitter / hogan.js

A compiler for the Mustache templating language
http://twitter.github.io/hogan.js
Apache License 2.0
5.14k stars 431 forks source link

New sections in childs are not taken into account #169

Closed jbrey closed 10 years ago

jbrey commented 10 years ago

Hi,

I'm starting with Hogan and I have a problem rendering section in childs. My templates should work with java implementation (with https://github.com/spullara/mustache.java) and with javascript.

As far as I understand, Hogan 3.0.0 provides the implementation of the inheritance just like the java implementation (https://github.com/mustache/spec/issues/38).

My problem is that the section's content in childs are not rendered (default or value), but it works with java.

Here is a (Jasmine) test that fails:

var child = Hogan.compile('{{<parent}}{{$a}}c{{/a}}{{$b}}b{{/b}}{{/parent}}').render({}, {
  parent: '{{$a}}p{{/a}}'
});
expect( child ).toBe( "cb" );

Note that I'm redefining a {{$b}} section with a default in the child.

Am I doing something wrong ? should it work ?

Thanks in advance JB

jazzdan commented 10 years ago

Hi JB,

I think you're understanding of the parent ("{{<") tag might be a little off. You can see an updated spec pull request based off of @spullara's work here

child "inherits from" parent. It then says "if child has block a, set the contents to c, if child has block b, set the contents to b. When it parses parent it finds block a and sets it to c (overriding the default you provided of p). Then it reaches the closing tag and stops, outputting c.

To get the behavior I think you are looking for, I would write the template like this:

var child = Hogan.compile('{{<parent}}{{$a}}c{{/a}}{{/parent}}').render({}, {
  parent: '{{$a}}p{{/a}}{{$b}}b{{/b}}'
});
expect( child ).toBe( "cb" );

Here it would parse child and say "if child has block a, set the contents to c." Then it when it parses parent it finds a and sets it to c. But since it has no value for b it takes the default value provided, 'b'. Then it renders: cb

Does that make sense?

jbrey commented 10 years ago

Hi Dan,

Thanks for this answer. Using this approach, it forces me to know all the regions on the parent so with several inheritance ,it might be a problem.

What I was trying to do in a more realistic sample:

{{!BasePage}}

<html>
    <head>
        {{$head}}{{/head}}
    </head>
    <body lang="{{lang}}" class="{{classes}}">
        {{$bodyRegion}}{{/bodyRegion}}
    </body>
</html>

{{!NavPage}}

{{<base}}
    {{$bodyRegion}}
        {{$bannerRegion}}
            default banner
        {{/bannerRegion}}

        <nav class="main-navigation">
            {{>navigation}}
        </nav>

        <div class="main-content">
            {{$contentRegion}}
            {{/contentRegion}}
        </div>

        <footer>
            {{$footerRegion}}
                default footer
            {{/footerRegion}}
        </footer>

    {{/bodyRegion}}
{{/base}}

Then I would have a login page which inherits the BasePage by defining the bodyRegion and several Page childs which inherit the NavPage by redifining the contentRegion and optionnally the other regions defined in NavPage.

and it works on java implementation, that's the reason why I thought it was an issue.

Looking at the specification you refer, I may solve my problem by using several parents, I will try...

Thanks again ! JB