Loved the blog post

26 views
Skip to first unread message

Ivor Paul

unread,
Sep 9, 2014, 3:53:19 AM9/9/14
to guardians-o...@googlegroups.com
Hi

Just wanted to say that reading the Temple post made me feel smarter :)

Looking forward to playing with Temple.
Thanks!

Magnus Holm

unread,
Sep 9, 2014, 4:13:30 AM9/9/14
to guardians-o...@googlegroups.com
Ha, cheers! That's very nice to hear.

This mailing list has been dead for a looong time. Feel free to ask questions and discuss, but right now it seems that template languages in Ruby is a pretty solved problems.
--
You received this message because you are subscribed to the Google Groups "Guardians of the Temple" group.
To unsubscribe from this group and stop receiving emails from it, send an email to guardians-of-the-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--

// Magnus Holm

Timothy N. Tsvetkov

unread,
Sep 13, 2014, 5:44:29 AM9/13/14
to guardians-o...@googlegroups.com
Hi, folks!

Three or four years ago I forked Liquid safe template language
(http://liquidmarkup.org) because it wasn't flexible enough for our
clients (for instance we wanted to give an ability to safely use
scopes and relations in templates). After we grew up some of our
client's templates became really big and complicated, load on our
servers increased, therefore we decided to compile templates to ruby
instead of parsing them using regexs on each request.

At first I was considering Temple as a solution. I think I even posted
here or dropped a letter to Magnus Holm about my plans on using Temple
to compile Liquid-like language and Magnus showed (sorry if it wasn't
you, i don't remember it well) his private attempt to compile some
Liquid-like template language. But then we hired a new developer who
just wrote a few parsers for different languages and wasn't negatively
obsessed on writing parsers (as I always was, mostly due to some
personal background), so we asked him to build a proper parser and
compiler for our template language. And it turned out that it wasn't a
big deal. Yes, of course, it took more then a day, but I think after a
week of work he delivered a fully refactored template engine with
revised and improved syntax, with parser generated for a defined
grammar, custom compiler and a solid syntax validation and error
reporting.

Defining a proper grammar and generating a parser for it simplified
syntax validation on saving (editing) and let us to find more syntax
errors we struggle to detect before. Needless to say that it let us to
report errors with more useful information, like line and column in a
template code where error was found/occurred (what we were unable to
do without switching from regex-based parser to a parser based on
grammar or without revising the way templates were parsed and
evaluated).

Please, don't get me wrong. Temple is a remarkable project and I
always liked it. But think why actually do you want to compile your
very own template language (and even why do you have one). Maybe it
would be better and eventually easier to define a proper grammar and
generate a parser using something like racc
(https://github.com/tenderlove/racc), which is LALR(1) [LALR(1) should
be enough for most template languages I can imagine] and then build
your own language specific compiler.

P.S. Here is a Liquid "fork" I mentioned:
https://github.com/evilmartians/liquor (NOTE: I don't support it
anymore, I don't have any private access to the repo, I don't work for
a company it was developed in anymore, etc, bla, bla, bla). So you can
look on its grammar and compiler.

P.P.S. And again, Magnus, sorry for suggesting here to use racc +
custom compiler instead of using Temple (in some cases).
Reply all
Reply to author
Forward
0 new messages