Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Mustache-alike generation. #43

Closed
adamsalter opened this Issue Oct 5, 2009 · 10 comments

Comments

Projects
None yet
5 participants

Raising an issue to open discussion. I don't know either Haml or Mustache codebase well enough to start work on this straight away.

Chris Wanstrath (aka defunkt) has just released a great template engine 'Mustache' based on Google's CTemplate.

As a templating solution Mustache is great, but I don't think anybody can deny the cleanness and readability of HAML code.

I don't think it would be too difficult to modify HAML to support Mustache-like generation. This could even be an option on HAML which could be turned on an off.

I'm thinking something like:

a) no ruby code evalution, so (-, =) no longer evaluate.

b) new syntax {{#boolean}}, {{helper}}, {{{non_interpreted_helper}}} can be used anywhere in the code(ie as nodes and inside text nodes) and will be evaluated as expected.

c) integration into rails could be very simple. All template logic now goes into the helpers files.

Collaborator

nex3 commented Oct 5, 2009

I think this would make the most sense as a separate library that integrated Haml and Mustache, probably most easily by simply passing the output of a slightly-modified Haml to Mustache. Haml has a :suppress_eval option that will suppress Ruby evaluation, which would help.

For Mustache nodes that take blocks (e.g. {{#foo}}), there could be some integration with Haml. This could be done hopefully without much difficulty by subclassing Haml::Precompiler.

That doesn't sound too painful. I'll have a look at it an get back to you.

clr commented Oct 5, 2009

Note that technicalpickles has a gem to use mustache with rails:
http://github.com/technicalpickles/mustache-ride
Best gem name ever.

Member

k0kubun commented Mar 28, 2017

It passed 8 years. Closing for now but feel free to reopen this.

@k0kubun k0kubun closed this Mar 28, 2017

Any updates on this? I would really like to use HAML with vue.js

Member

k0kubun commented Apr 13, 2017

In vue.js, what kind of input and output do you want in Haml? And which Haml feature prevents that?

@k0kubun k0kubun reopened this Apr 13, 2017

Haml outputs erb using its equal-sign shorthand, vuejs uses mustache syntax.

So here's what haml will output for erb: %h1= message => <h1><%= message %></h1>

Whereas if you were to use vuejs, it would be ideal (but not neccecary and probably not hard to implement as a config feature) if it did this:
%h1= message => <h1> {{ message }} </h1>

Member

k0kubun commented Apr 15, 2017 edited

Haml outputs erb using its equal-sign shorthand, vuejs uses mustache syntax.
So here's what haml will output for erb: %h1= message => <h1><%= message %></h1>

In precise, Haml doesn't output erb. It outputs just Ruby code. But probably I know what you mean.

Whereas if you were to use vuejs, it would be ideal (but not neccecary and probably not hard to implement as a config feature) if it did this:
%h1= message => <h1> {{ message }} </h1>

Now we have code generator layer in Haml. At first I can do that easily as you say. But it was not that truth.

In the layer for message, we have ::Haml::Helpers.html_escape(..) for html_escape, .to_s to render correctly as old behavior, "_hamlout.attributes({ \"foo\".freeze => _haml_attribute_compiler1 }, nil)" to render dynamic attributes.

So, you can get the behavior in a "not hard to implement" way.

input

%h1= message

expected output

<h1>{{message}}</h1>

actual output (for Sinatra, not HTML-escaped by default)

<h1>{{((message
).to_s).to_s}}</h1>

actual output (for Rails, HTML-escaped by default)

<h1>{{(_hamlout.fix_textareas!(::Haml::Helpers.html_escape(((message
)).to_s));).to_s}}</h1>

I think this is not what you want.

Then, we need to create "Temple filter" to change that behavior and combine Haml's original Temple filters with them. But it'll require many sources limited for that feature (especially for removing to_s. And for now I don't want to do that in Haml gem layer). Thus I agree with nex3 in the point that "this would make the most sense as a separate library".

Again, as nex3 said, this should be implemented as a separate library, and it is possible now because we implemented Haml with Temple. Thus it's welcomed to create such gem. But I'm not using vue.js for now and I have no motivation to create that.

Member

k0kubun commented Apr 15, 2017

Since now it's not issue for Haml gem itself, closing. The reporting comment to create such gem would be appreciated if someone achieves it.

@k0kubun k0kubun closed this Apr 15, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment