Guardians of the Temple Google Group

Re: html_safe issue with partials

jolis...@gmail.com (Jo Liss) — Wed, 22 Feb 2012 14:54:23 UT

I see. First of all, thanks for your explanations!
Between the complexity of (1) making the generator an option and (2)
using a raw Rails template handler with ...
def call(template)
# Return Ruby code that returns the compiled template
@markdown.render(template.sour ce).inspect + '.html_safe'

Re: html_safe issue with partials

judo...@gmail.com (Magnus Holm) — Wed, 22 Feb 2012 13:36:00 UT

Probably :-)
I think this is because you're now using Temple's array-buffer (which
Rails will escape), while ERB/Slim uses ActiveSupport's buffer. If you
change the generator to an option, you can override it later:
class Engine
set_default_options :generator => Temple::Generators::ArrayBuffe r

html_safe issue with partials

jolis...@gmail.com (Jo Liss) — Wed, 22 Feb 2012 13:03:57 UT

Hey guys,
I am implementing a markdown-rails gem, for static views and partials
written in Markdown. (It's at
[link], though it's alpha software
and might still be rebased.) I tried using Temple for it, and I have
two question for you:
Firstly, is it reasonable to use Temple at all, given that I'm only

Serenade.js template syntax

judo...@gmail.com (Magnus Holm) — Wed, 08 Feb 2012 13:41:26 UT

Alright, this is interesting: [link]
It has Slim/Haml-ish syntax, but with some few changes. Most notably,
all literal strings need to be enclosed in quotes:
body
h1 "Hello World"
At first I was like "meh", that's verbose, but then I realized it has
several advantages:

Re: Cross-compilation with Temple (and announcing Skim -- client side Slim with embedded CoffeeScript)

john.fireba...@gmail.com (John Firebaugh) — Thu, 02 Feb 2012 03:08:16 UT

For a Ruby webapp developers specifically -- the target audience for
Temple-based languages -- I would actually argue the opposite. It's less
useful and makes everything harder. Look at a template engine like Haml
that started out as a Ruby library. It gets ported to JavaScript to run
client-side (haml-js), but it turns out we'd rather serve the client

Re: Cross-compilation with Temple (and announcing Skim -- client side Slim with embedded CoffeeScript)

judo...@gmail.com (Magnus Holm) — Wed, 01 Feb 2012 09:38:50 UT

The reason I haven't made Temple more language-agnostic is that it's
much more useful to have the template engine implemented in the same
language as the runtime language; less dependencies, more dynamic
possibilities (see Handlebars-JIT and Heffigy) and it makes everything
easier.
If we want to go this way, it means we'll need to more clearly specify

Cross-compilation with Temple (and announcing Skim -- client side Slim with embedded CoffeeScript)

john.fireba...@gmail.com (John Firebaugh) — Mon, 30 Jan 2012 01:17:02 UT

Hi all,

My desire for using Slim as a client-side templating language led me
to explore the feasibility of using Temple in a cross-compilation
scenario. My goal was implement a Slim-alike language (called Skim)
that embeds CoffeeScript rather than Ruby and compiles to a JavaScript
template (JST) function. My strategy for getting there was to reuse as

Re: Keep your peanut butter out of my chocolate.

br...@metabahn.com (bryanp) — Fri, 27 Jan 2012 15:28:40 UT

First, thanks for the response. I appreciate the questions and the
opportunity to bring clarity to some of the points in my original post.
Hopefully this discussion will continue as that's the most likely way to
encourage innovation.

templates is something that *builds* a structure depending on the data

Re: Keep your peanut butter out of my chocolate.

judo...@gmail.com (Magnus Holm) — Thu, 26 Jan 2012 09:55:21 UT

(Response to [link]
sent to the author + a mailing list)
This is a flawed definition because logic also changes structure:
<div class="results">
<% if @results.empty? %>
<h2>Sorry, your search returned no results</h2>
<% else %>
<% @results.each do |res| %>

Mockie; cross-site requests of static HTML files

judo...@gmail.com (Magnus Holm) — Thu, 26 Jan 2012 08:50:22 UT

You might be interested in this: [link]
Mockie is a development tool for fetching stuff from static HTML
files. Doesn't sound very interesting at first, but it has one big
advantage of AJAX (or Flash or whatever): cross-site requests just
works; no configuration needed! Checkout the README for how you could

Re: Handlebars Implementation?

judo...@gmail.com (Magnus Holm) — Sun, 21 Aug 2011 10:49:09 UT

Not that I know about…
// Magnus Holm

Handlebars Implementation?

abhis...@gmail.com (Asaxena) — Sat, 20 Aug 2011 02:49:50 UT

For handlebars in ruby there's the hbs gem which uses rubyracer,
however there are some issues with this implementation.

Does anyone knows of any handlebars implementation that is based on
Temple? Doesn't have to be complete, just hackable :)

Re: N-step compilation in template interfaces

josteinp...@gmail.com (Jostein Berre Eliassen) — Sat, 28 May 2011 10:41:19 UT

I think Temple is great, and it was part of my inspiration. With
Shift, I am essentially trying to make a much more generic uncle of
Tilt. For now you can do things like
Shift.read("cup.coffee.gz").in flate.compile.minify.gzip.writ e, which
would read the file, inflate it, compile it, minify using the best

Re: N-step compilation in template interfaces

judo...@gmail.com (Magnus Holm) — Tue, 24 May 2011 13:38:40 UT

Hi Jostein!
Very interesting! You might be interested in Temple which essentially
is a N-step compilation framework for template engines:
[link]
// Magnus Holm
On Sun, May 15, 2011 at 12:07, Jostein Berre Eliassen

N-step compilation in template interfaces

josteinp...@gmail.com (Jostein Berre Eliassen) — Sun, 15 May 2011 10:07:09 UT

Hi :)

The group seems a bit sleepy, but here we go.

The way i see it, Tilt thinks of template rendering as a two-step
process -- and rightfully so, unless you are working with Sass,
CoffeeScript, or a JavaScript compressor. I was playing around,
working on a Tilt-like framework for formats that compile in one step,