Mysterious Ruby-Block-Verhalten: & Block gegen {block.call}

Question

Wenn zum Drucken von Javascript einen Helfer zu schreiben, die sowohl von anderen Helfern und Ansichten verwendet werden können, stieß ich auf das folgende Problem:

def javascript(print_tag = false, &block) 
    content_for(:javascript) do 
    if print_tag 
     javascript_tag(&block)   # does not work 
     javascript_tag { block.call } # does work 
    else 
     capture(&block) 
    end 
    end 
end 

Dieser Helfer sollte mit javascript { "alert('hurray'); } aufgerufen werden.

In der ersten Alternative - die ich erwartete zu arbeiten - die Rails javascript_tag helper rendert eine leere <script type="text/javascript"> //<![CDATA[ //]]> </script>-Tag.

Die zweite Alternative funktioniert jedoch wie erwartet.

Was ist dort los? Wie kann das anders sein?

Answer 1

Sie sagen, Sie tun dies auf Ihre Ansichten, richtig?

<%= javascript { "alert('hurray');" } %> 

Aber für content_tag(&block) arbeiten zu können, javascript die Art und Weise nennen sollte content_tag in Ansichten verwendet werden soll, das ist:

<% javascript do %> 
    alert('hurray'); 
<% end %> 

content_tag ‚s Verhalten unterscheidet je nachdem, wo es aus aufgerufen wird , siehe die Funktion block_called_from_erb? im Quelltext. Im ersten Fall gibt diese Funktion true zurück, weil der Block von einem erb kommt (und dann ist es concat ed, das wollen Sie nicht!), In der zweiten gibt false (Sie haben den Block von Grund auf neu erstellt) und content_tag einfach gibt den String-Inhalt zurück, den Sie haben möchten.

# ./action_view/helpers/javascript_helper.rb 
tag = content_tag(:script, javascript_cdata_section(content), html_options.merge(:type => Mime::JS)) 
if block_called_from_erb?(block) 
    concat(tag) 
else 
    tag 
end