2012-02-07 10 views
9

w szynach 3,0 haml (3.1.4) Mamcontent_for vs uzysk podszablonów

  1. pewne szablonu jak częściowe, jak _template.html.haml:

    .panel.top 
        = yield :panel_top 
    
    .content 
        = yield 
    
  2. jakiś inny częściowy który będzie wyświetlany przy użyciu szablonu prev (wszystkie te rzeczy są renderowane za pomocą AJAX, ale to nie ma znaczenia)

    - content_for :panel_top do 
    .title.left 
        = title 
    
    content text 
    

i to działało jak czar w szynach 3,0

Ale, po uaktualnieniu do 3.2 to się nie powiedzie! Yiels tylko daje „text content”, więc mam „tekst treści” dwa razy i nie tytuł na wszystkich

tylko zmienia = yield :panel_top do = content_for :panel_top prace za 3,2

nie jestem pewien, że to rozwiązanie jest ok, a jeśli jest stabilny lub zalecany, nie mogę znaleźć żadnych uwag na temat zmian w przetwarzaniu yield ani w informacjach o wydaniu Rails 3.1, ani w 3.2.

Czy możesz pomóc w jaki sposób najlepiej zorganizować wewnętrzne części?

Odpowiedz

10

Od Rails 3.0 do Rails 3.2 content_for naprawdę zmieniło:

3,0:

def content_for(name, content = nil, &block) 
    content = capture(&block) if block_given? 
    @_content_for[name] << content if content 
    @_content_for[name] unless content 
end 

3,2:

def content_for(name, content = nil, &block) 
    if content || block_given? 
    content = capture(&block) if block_given? 
    @view_flow.append(name, content) if content 
    nil 
    else 
    @view_flow.get(name) 
    end 
end 

To pokazuje nam, że z 3,2 content_for prac do pokazywania/wstawiania treści nie tylko przechowuj go lub nazwana sekcja.

Ponadto, jeśli podejmiesz próbę debugowania logiki yield, uzyskasz wynik przed prawidłowym zainicjowaniem content_for.

Więc, pozostawiając buforowania fragment z tej dyskusji mogę stwierdzić, że content_for jest preferrable sposób wstawić nazwane sekcje nigdzie z wyjątkiem układów najwyższego poziomu. W pomocnikach i innych sytuacjach, yield powinien renderować błędne wyniki.