On Sun, Oct 17, 2010 at 11:26, Timothy N. Tsvetkov <
timothy.tsvet
...@gmail.com> wrote:
> I forked Liquid and extended a bit. My fork now works in production
> well for us but it is slow because Liquid is slow. Our response time
> is ok for our customers, but I start working on boosting my fork of
> Liquid. And now looking for libs for compiling it or maybe I should
> write my own one? Have you tried Temple? What do you think about it?
> On Sep 10, 9:11 pm, Magnus Holm <judo...@gmail.com> wrote:
> > Hey folks,
> > There's several context-stack-based template engines now: The main
> > idea with them is that instead of using Ruby, you write in a custom
> > markup language and there's an implied stack which changes the lookup:
> > Example from Mustache/Handlebars.js:
> > {{name}} <- Refers to a top-level name-attribute
> > {{#projects}}
> > # The stack is pushed with the projects data.
> > {{name}} <- Could refer to the name of a project, or a top-level
> > name-attribute
> > {{/projects}}
> > # The stack is popped
> > {{name}} <- Refers to the top-level name-attribute again
> > Liquid:
> > {% for a in b %}
> > # The stack is pushed with `a`
> > {{ a.name }}
> > {% endfor %}
> > # The stack is popped, `a` is no longer available
> > There's probably several places where all of these engines can share
> > code (maybe only have different parsers) and by doing this the
> > Temple-way they can all take advantage of different optimizations. For
> > instance, I've written Handlebars-JIT which speeds up Mustache with
> > 2x, but the same idea can also be applied to all of these engines.
> > Supporting both Mustache and Handlebars.js (by wycats) would the first
> > goal, but as it's written we should build it in such a way that it's
> > simple to include support for Liquid and other context-stack-based
> > template engines.
> > Any thoughts?
> > // Magnus Holm
