Haml 2.0

Tried to digg this, but digg failed epicly.

Anyway, so awesome! Can’t wait to wake up tomorrow and play with the new features! d-:

“To turn on HTML-escaping by default, set the :escape_html option to true in whatever way your framework provides.”

Might be useful to provide at least one example for how to do this. Rails for example. And the :ugly option too. I have no idea where to start looking for this.

I’m already loving Friendly Fred. Great job ! \o/

Great work by Nathan and all of the contributers for helping us hit this milestone in the haml community! I couldn’t ask for a more passionate and amazing community!

Great news, looking forward to trying this out!

This totally thrills me! SASS 2.0 will open up a bunch of doors for me. Looking forward to the progression of this language. Keep it up!

does it work with Rails edge?

Sass mixins are a fantastic feature! Thanks for the continued work to improve Haml and Sass!

I’m glad everyone’s so pleased :-).

Anonymous: I’ve added a bit about setting options to the HTML Escaping section.

Joe: Yes it does… for now. If Rails edge changes their template-handling mechanisms in the future, only the master and stable branches will be compatible until Haml 2.0.1 is released.

One thing to consider for the future is to promote HAML in different languages. Maybe HAML doesn’t have to just be a Ruby thing.

Thank you for the new features.

I have been reluctant to hack HAML (i.e. 1.8.2) but I eventually relented and added the following code after def surround in lib/haml/helpers.rb (I needed something more than surround). I’ve just discovered the new features that enable me to dispense with my hack, but here’s my hack (for discussion, there may still be a place for these):

def substitute(find,replace, &block)
  output = capture_haml(&block)
  "#{output.chomp.gsub(find,replace).chomp}\n" 
end

def concat(with = '', &block)
  substitute("\n", with, &block)
end

Example:

= concat ' | ' do
  = link_to 'Logout',  :action => 'logout'
  = link_to 'Change',  :action => 'change'
  = link_to 'Refresh', :action => 'refresh'

or even:

= surround '[ ', ' ]' do
  = concat ' | ' do
    = link_to 'Logout',  :action => 'logout'
    = link_to 'Change',  :action => 'change'
    = link_to 'Refresh', :action => 'refresh'

Thanks also for the javascript filter. I want to create a slightly more efficient result when using it than from the following (i.e. replace repeated script containers with just one)

- unless @special_elements.blank?
  - @special_elements.each do |element|
    :javascript
      make_special('#{element.first}', #{element.last});

which produces:

<script type='text/javascript'>
  //<![CDATA[
    make_special('panel1', ...);
  //]]>
</script>
<script type='text/javascript'>
  //<![CDATA[
    make_special('panel2', ...);
  //]]>
</script>

How can I achieve (note: lines 2 and 3 are swapped)

- unless @special_elements.blank?
  :javascript
    - @special_elements.each do |element|
      make_special('#{element.first}', #{element.last});

to produce

<script type='text/javascript'>
  //<![CDATA[
    make_special('panel1', ...);
    make_special('panel2', ...);
  //]]>
</script>

I have a feeling you might say, “Do that in the controller”. The thing is that @special_elements is filled in by the various views that are generated (i.e. after the controller has run). If you could make this work, it would be pretty neat. I know it goes against the filter concept somewhat, but that could be a powerful concept if you could achieve such embedded control. Anyway, I look forward to your comments.

Thank you for HAML/SASS. I appreciate the contribution. It is a good philosophy to enforce MVC (well, at least to very strongly encourage MVC), particularly as neatness (elegance and conciseness) is a valuable result.

I hope you can tell that I am a fan! Sorry for the multiple comments in a row. Please note that I am holding back!

Anyway, can I suggest or request that

%div[@user, :greeting]
  %bar[290]/
  Hello!

be equivalent to

[@user, :greeting]
  %bar[290]/
  Hello!

because it follows the same pattern with # and . in that if the tag is omitted then it is assumed to be a div (i.e. Implicit Div Elements)?

Last one (for now).

I’m not sure if this is a bug, but it is at least a warning if you are doing something similar; otherwise, I’ve stuffed it up somehow. For a login form (i.e. if you use form_tag) in RubyOnRails, you have to put the end in.

... #login_panel
      - make_special('login_panel',...)
      .form
        = form_tag :action => :login do
          = text_field_tag :name, params[:name], :size => 30
          = password_field_tag :password, params[:password], :size => 30
          = submit_tag 'Login'
        - end       <-- doesn't work if left off, HAML doesn't auto close this one

The last end is necessary. This is a Rails thing and might be beyond HAML to account for it.

P.S. While I’ve got this code up there, can I make another feature request (just to make things a little DRYer)? Can you provide a variable which contains the id (if there is one) of the current container? This would be useful to me for many things, but this simple example will give you the idea.

... #login_panel
      - make_special('login_panel',...)
      .form

would become (or something similar, with some tasteful and appropriate escape sequence)

... #login_panel
      - make_special(@@@id,...)
      .form

or a namespace polluting solution such as

... #login_panel
      - make_special(@view.current_dom_id,...)
      .form

If you think that is too yuck, then I understand. I think it is worth talking about. Is there a difference between being DRY and being lazy?

Cheers and thanks again.

Ryan: There are already numerous alternate implementations of Haml, including two in PHP (phpHaml and pHaml), one in Python, and one in C#. There may be more that I haven’t heard about yet. I’ve been thinking of 2.0 as a time to start working on unifying these alternate implementations, thinking about what it means to be “Haml,” and so forth.

Luis: I can see how those helpers would be useful. I’m not convinced that it’s not a better idea to do Array#join in a helper.

For the :javascript stuff, filters are really meant to be used with primarily static text. I’d do that with

- unless @special_elements.blank?
  %script{:type => "text/javascript"}
    - @special_elements.each do |element|
      &== make_special('#{element.first}', #{element.last});

We may make [] trigger the default-div behavior in the future. I’ve been able to get form_for to work without an extra end… I can’t imagine why it wouldn’t for you. And finally, I think adding support for class- and id-insertion would either cause too many performance issues or force us to run #gsub on some Ruby code, neither of which I want to do.

Thank you, Nathan, for your replies.

I do agree to not overlook using a helper and Array#join. I think it is easy for people to overlook them because when MVC is talked about, it is not presented as MVHC (H = Helper) and they kind of get left out until later.

I am tempted to try to convince. I think there does exist a sensible use case, but it’s not going to be very common. I think the best shot at it is that concat is conceptually between surround and list_of, and could/should be included for completeness. substitute could allow for some interesting post-processing of HTML. Those uses maybe a bit pathological but could be useful. I would like a more general form of list_of, but the answer is ultimately to use a helper. I do like that the resultant HTML is neatly indented. A helper can’t always make sure that indentation is correct, which is what is luring me out of a helper somewhat.

One drawback with using

%script{:type => "text/javascript"}

is that the CDATA is not included. I think you would need to do

%script{:type => "text/javascript"}
  !== //<![CDATA[
  make_special('panel1', ...);
  make_special('panel2', ...);
  !== //]]>

but then the Javascript code is not indented. :-( Is there a better solution?

The form_for is OK. It’s form_tag that’s the problem. I’ll have another look and see if I can post some useful information (hopefully it’s not that I’m a dummy!).

That’s quite fair enough to avoid performance issues with adding support for class- and id-insertion. It’s great how fast HAML is. I think an efficient alternative to using a gsub would be to venture into namespace polluting which could be an option

Haml::Template.options[:pollute_dom_ids] = true

or

Haml::Template.options[:store_dom_ids_in] = @dom_id_containment

Then when you go into the new scope do

Haml::Template.options[:store_dom_ids_in].push id

and when you leave the new scope do

Haml::Template.options[:store_dom_ids_in].pop

that way you could access the full containment of elements (even across partials), e.g.

... #login_panel
      - make_special(@dom_id_containment.last,...)
      - @domains.each do |domain|
        [@domain]
          - add_ajax_commands(@dom_id_containment,...)
          ...

I hope this makes sense. Can you see where I am going? I like neatness. ;-) Particularly, when neatness also produces speed!

Yehaa! The Whitespace-War is over ;-)

When I was confronted with the whitespace issue the first time, I intuitively added an trailing backslash to the line – but that obviously didn’t work. Have you thought about this solution?

BTW, the URLs in your (atom) feed don’t include the domain :-(

Luis: Helpers have various tools available to them for properly indenting their output, including using tab_up/tab_down, haml_tag, puts, or just returning a string that’s auto-indented by Haml. And in general, I’d be very nervous about just doing a gsub on newlines… what if there were newlines where we didn’t expect them? It seems way too dangerous.

In general, if you’re dynamically generating Javascript, you can HTML-escape it yourself (as I did in the example above), thus removing the need for CDATA. If you do need it, though, you could just write a simple helper.

The dom id detection isn’t as simple as that. Haml has distinct compilation and runtime phases, and the id may or may not be known in either of those. If it’s possible to implement this at all, it would require a huge amount of added complexity, and I just don’t think it’s worth it.

Dominik: Haml does have multiline syntax using |, the pipe character. The syntax is intentionally awkward, though; see question three in the Haml FAQ.

My feed has the xml:base attribute set, which provides the domain for domainless URLs. If your feed reader doesn’t process that, I suggest you submit a feature request ;-).

Thanks Nathan. You are quite right. I think that answers the question about the difference between being DRY and being lazy. I think I was advocating laziness. The Javascript example is probably best done by:

- unless @special_elements.blank?
  = javascript_tag(@special_elements.collect{|element| "make_special('#{element.first}', #{element.last});"}.join("\n")

which, with a helper, would become

= special_elements_javascript

All nice and neat. Yes, much better. Same with the dom id business. Thank you for spending the time responding.

Another counter to my argument would be to write a custom filter. But, I think you’re right: it’s just wrong. It’s best to focus on HAML being fast. Being faster than ERB is a good thing.

Also, I really like SASS errors coming up in the page. Great work!

I’ve been using the clearfix mixin trick for a while now (http://wonderfullyflawed.com/2008/05/21/clearfix-as-mixin/). Happy to see it make it off edge and into the wild!

I’d like to see escaped Ruby for use as a comment language, replacing my use of markdown.