9 ms·
Yes to else sections. The lack of else is just plain annoying after awhile. Don't care on dotted access. Context addressing is fine if we can agree on a metho
by davisp 16y ago
Yes to else sections. The lack of else is just plain annoying after awhile.
Don't care on dotted access.
Context addressing is fine if we can agree on a method and keep the spec simple. Perhaps using Git's SHA addressing with things like HEAD, HEAD^, HEAD^^ or similar.
Yes to booting dynamically changing delimiters.
Yes to stealing helpers.
For cross-language compatibility, we really should have a collection of test inputs and outputs.
We should adopt a directive thing like you have for the 'this' notation with {{.}} or whatever for lists. The original is a bit funny looking but I think this sort of thing would fix the delimiter issue.
Another pattern that I run into that's a bit weird is when I need to add markup around a list when its not empty. I end up having a context that returns a context with a rows object when there is data, or None when there are no rows. So it looks like this in mustache:
{{#genes}}
open table
{{#rows}}
row stuff
{{/rows}}
end table
{{/genes}}
I keep having the feeling there's a better way to make that work.
If I get another project finished up shortly I'll write these up in a branch of pystache.
- judofyr 16y ago> For cross-language compatibility, we really should have a collection of test inputs and outputs. https://github.com/mustache/spec https://github.com/mustache/spec
- deleted 16y ago[deleted]
- binspace 16y ago> {{#genes}} open table {{#rows}} row stuff {{/rows}} end table {{/genes}} JSON templates has an interesting solution. http://json-template.googlecode.com/svn/trunk/doc/Introducing-JSON-Template.html http://json-template.googlecode.com/svn/trunk/doc/Introducin... {.section genes} open table {.repeated section @} row stuff {.end} end table {.end}