I am implementing a markdown-rails gem, for static views and partials
written in Markdown. (It's at
https://github.com/joliss/markdown-rails, 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
generating [:static, '... compiled HTML ...'], or do you think it's
overkill?
Secondly, do I have to do something in particular to get partials to
work (<%= render :partial => '...' %>)? Right now all the HTML from
the partial ends up escaped with < etc., presumably because it's
not html_safe. This doesn't happen with Erb, Slim, and friends. Here
is an app that demonstrates the problem:
git clone g...@github.com:joliss/markdown-rails.git
cd markdown-rails
git checkout 7b5d7f8 # HEAD does not use Temple at the moment
cd testapp
rails server
http://localhost:3000/ # works
http://localhost:3000/partial # has < escaped as <, etc.
The views are in testapp/app/views/home/. The code is at
lib/markdown/rails/engine.rb, or
https://github.com/joliss/markdown-rails/blob/7b5d7f8/lib/markdown/rails/engine.rb
Any hints would be appreciated!
Thanks,
Jo
--
Blog: http://www.opinionatedprogrammer.com/
Business: http://www.votingsoftware.org/
Probably :-)
> Secondly, do I have to do something in particular to get partials to
> work (<%= render :partial => '...' %>)? Right now all the HTML from
> the partial ends up escaped with < etc., presumably because it's
> not html_safe. This doesn't happen with Erb, Slim, and friends. Here
> is an app that demonstrates the problem:
>
> git clone g...@github.com:joliss/markdown-rails.git
> cd markdown-rails
> git checkout 7b5d7f8 # HEAD does not use Temple at the moment
> cd testapp
> rails server
>
> http://localhost:3000/ # works
> http://localhost:3000/partial # has < escaped as <, etc.
>
> The views are in testapp/app/views/home/. The code is at
> lib/markdown/rails/engine.rb, or
> https://github.com/joliss/markdown-rails/blob/7b5d7f8/lib/markdown/rails/engine.rb
>
> Any hints would be appreciated!
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::ArrayBuffer
use(:Generator) { options[:generator].new(options) }
end
engine = Engine.new(:generator => Temple::Generators::RailsOutputBuffer)
That said, Temple also supports Rails out of the box:
class Parser
def initialize(options = {})
@options = options
@markdown = Redcarpet::Markdown.new(Redcarpet::Render::HTML)
end
def call(exp)
[:static, @markdown.render(exp)]
end
end
class Engine < Temple::Engine
use ::Markdown::Rails::Parser
set_default_options :generator => Temple::Generators::ArrayBuffer
use(:Generator) { options[:generator].new(options) }
end
RailsEngine = Temple::Templates::Rails(Engine, :generator =>
Temple::Generators::RailsOutputBuffer)
RailsEngine.register_as(:md)
RailsEngine.register_as(:markdown)
Notice how Parser#call now takes a string instead of a Rails-template.
--
Man, we really have terrible docs. And I'm not 100% satisfied with the
option/generator overriding. But whatever.
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.source).inspect + '.html_safe'
end
... I think option (2) looks slightly less ugly, if only because it's
shorter. I think I'll leave this for now.
> Man, we really have terrible docs.
I'd love to say it ain't so, but it was pretty painful indeed. ;-) I'd
send you a pull request for the README, but I'm not really
knowledgeable enough to be of much help. Rails's documentation on
template handlers is pretty lacking too, for what it's worth. It took
me a while to figure out that `call` is supposed to return evalable
code.
Anyways, thanks for your help!