Support for 'section functions' #26

Closed
wants to merge 2 commits into
from

Conversation

Projects
None yet
3 participants
@pepve
Contributor

pepve commented Apr 13, 2012

The mustache manual (http://mustache.github.com/mustache.5.html) describes a feature in the Lambdas section that I think is not implemented in Mu. I'm calling it 'section functions' now, I don't know if that's correct. If I understand the manual correctly, it means that {{#a}}foobar{{/a}} with { a: function (body) { return body.substr(3); } } should evaluate to bar. I added a test for this behaviour and implemented it. Please let me know what you think.

Pepijn Verlaan added some commits Apr 13, 2012

Pepijn Verlaan
add failing test for section functions, that is, functions that take …
…full responsibility to render the content of the section they're called on
@raycmorgan

This comment has been minimized.

Show comment Hide comment
@raycmorgan

raycmorgan Apr 14, 2012

Owner

I am going to look more into this. Your code looks like it is implementing half of the "lambda" spec, since it also requires a render function which makes things a bit more complex.

Cases:

  1. They just render the text as is, optimized case would just reenter normal render pipeline.
  2. They modify the text, then render (no new partials). This would just have to re-compile that string, but compiling speed is not optimal, so this would have performance impacts.
  3. They modify the test, then render, and it includes an uncached partial. This would require either a) an async lambda interface, b) sync file access, or c) simply throw an exception.

Just some thoughts. I will likely merge this in, since it is closer to the goal.

Thanks for you additions.

Owner

raycmorgan commented Apr 14, 2012

I am going to look more into this. Your code looks like it is implementing half of the "lambda" spec, since it also requires a render function which makes things a bit more complex.

Cases:

  1. They just render the text as is, optimized case would just reenter normal render pipeline.
  2. They modify the text, then render (no new partials). This would just have to re-compile that string, but compiling speed is not optimal, so this would have performance impacts.
  3. They modify the test, then render, and it includes an uncached partial. This would require either a) an async lambda interface, b) sync file access, or c) simply throw an exception.

Just some thoughts. I will likely merge this in, since it is closer to the goal.

Thanks for you additions.

@pepve

This comment has been minimized.

Show comment Hide comment
@pepve

pepve Apr 16, 2012

Contributor

I didn't really understand what the render function in the example was supposed to do at first (it is unbound). Thanks for your explanation. I currently don't need it though, I'll refer back to this if/when I do.

On the other hand, the async interface seems like the route to take. Maybe I should give this an async interface, to make it more future compatible?

Edit: maybe something like this? It even allows you to use renderText() for not-so-optimal rendering.

Contributor

pepve commented Apr 16, 2012

I didn't really understand what the render function in the example was supposed to do at first (it is unbound). Thanks for your explanation. I currently don't need it though, I'll refer back to this if/when I do.

On the other hand, the async interface seems like the route to take. Maybe I should give this an async interface, to make it more future compatible?

Edit: maybe something like this? It even allows you to use renderText() for not-so-optimal rendering.

@michaelwittig

This comment has been minimized.

Show comment Hide comment
@michaelwittig

michaelwittig Jun 11, 2012

Are you planing to implement Lambdas?

Are you planing to implement Lambdas?

@pepve

This comment has been minimized.

Show comment Hide comment
@pepve

pepve Jun 17, 2013

Contributor

I've gone with a different approach for my own fork. It's incompatible with this (but much more versatile), so I'm closing this pull reuest. Let me know if you think my new approach has merit for Mu itself.

Contributor

pepve commented Jun 17, 2013

I've gone with a different approach for my own fork. It's incompatible with this (but much more versatile), so I'm closing this pull reuest. Let me know if you think my new approach has merit for Mu itself.

@pepve pepve closed this Jun 17, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment