Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

can.Mustache - with context lost in nested sections #215

Closed
iamnoah opened this issue Dec 18, 2012 · 2 comments
Closed

can.Mustache - with context lost in nested sections #215

iamnoah opened this issue Dec 18, 2012 · 2 comments
Labels
Milestone

Comments

@iamnoah
Copy link
Contributor

iamnoah commented Dec 18, 2012

Here's a test case:

var renderer = new can.Mustache({text:'{{#with foo}} {{#if loaded}} {{#if ready}} Ready! {{else}} Not Ready {{/if}} {{else}} Loading... {{/if}} {{/with}}'});
var data = {
    foo: {
        loaded: true,
        ready: true
    }
};
var result = renderer.render(data);

equal(can.trim(result),"Ready!");

Here's the template:

{{#with foo}}
  {{#if loaded}}
    {{#if ready}}
      Ready!
    {{else}}
      Not Ready
    {{/if}}
  {{else}}
    Loading...
  {{/if}}
{{/with}}

The problem is that the context for if ready is the top level context, not foo.

I'm motivated to fix this, but could use a hint. My guess is that the context stack is backwards or that the with helper should be able to set this instead of just the context argument.

@ghost ghost assigned andykant Dec 20, 2012
@andykant
Copy link
Contributor

The problem with this is with the context(s) that the with helper passes. I'm looking into a solution, but this might require the with helper to be implemented in a different way (maybe just treat it exactly as a Mustache section instead of implementing it as a helper).

In the meantime, you can use regular Mustache syntax as a workaround:

{{#foo}}
  {{#if loaded}}
    {{#if ready}}
      Ready!
    {{else}}
      Not Ready
    {{/if}}
  {{else}}
    Loading...
  {{/if}}
{{/foo}}

@andykant
Copy link
Contributor

This was fixed with the fix for #228. #228 ended up being a dupe of #215.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants