2013-07-22 18 views
32

w szynach, często uruchamiane w sytuacji, w której wewnątrz poglądów zrobię cośJeśli else w .html.erb w widokach

<% if @some_condition_previusly_established_in_a_controller %> 
<div class="one">123</div> 
<% else %> 
<div class="two">something else</div> 
<% end %> 

Wygląda nieco cluttery. Czy jest to akceptowalny sposób pracy z widokami, czy nie?

+9

Można użyć <% -%> uniknąć puste wiersze mają być dołączone do otrzymanego kodu HTML. –

Odpowiedz

19

ile można wymyślić sposób, aby ponownie napisać to jako metodę pomocniczą, jesteś w zasadzie skazani na to patrząc rodzaj brzydki. Tak właśnie wygląda ERB, ponieważ miał to być minimalny sposób wprowadzania Ruby do szablonu w zwykłym tekście, a nie jako czegoś koniecznego usprawnionego lub eleganckiego.

Dobrą wiadomością jest edytor podświetlania składni, który zazwyczaj powoduje, że bloki ERB <% ... %> wyglądają inaczej niż HTML, co znacznie poprawia czytelność.

Jest to także, dlaczego inne reprezentacje, jak HAML zostały stworzone jeżeli składnia jest dużo mniej zaśmiecone:

- if some_condition_previusly_established_in_a_controller 
    .one 123 
- else 
    .two something else 
+2

Takich rzeczy jest, dlatego wolę HAML ponad ERB. HAML pozbywa się bałaganu. –

+0

Mam problem z HAML (używam slim). Składnia HAML jest jasna i zwięzła, gdy Twój kod HTML jest krótki. ale stanie się bałagan, gdy kod jest duży. Nie możesz również formatować kodu, gdy używasz niektórych IDE lub wtyczek .... – hqt

+0

@Hqt HAML jest całkiem niezły, dopóki twoje wstawione fragmenty kodu nie staną się zbyt duże, to prawda, ale zazwyczaj możesz to złagodzić pisząc funkcje pomocnicze, które minimalizują ilość kodu masz w swoim szablonie. Jak zauważyłeś, istnieją również inne systemy notacji meta-HTML podobne do HAML, więc jeśli nie jesteś zadowolony z ERB, masz opcje. – tadman

9

Dla jednej lub dwóch takich warunkowego logiki w swoich poglądów, chyba jest w porządku, ale gdy kod dostaje większe i masz wiele if..else..end i wygląda "cluttery", myślę, że powinieneś spojrzeć na realizację "Presenter Pattern", który znacznie oczyszcza swoje poglądy poprzez oddzielenie logiki od Presenters.

Oto świetny samouczek, którego obserwowałem od Ryana Batesa w jego serii Rails Casts na temat "Presenter Patterns from scratch". http://railscasts.com/episodes/287-presenters-from-scratch.

+0

Ładny link, ale niewidoczny dla osób bez konta płatnego. = ( –

+0

Tak, jestem zaniepokojony, jeśli naruszę prawa autorskie, gdybym opublikował link do źródła Github, postaram się umieścić link do źródła i edytować moją odpowiedź, aby dołączyć niezbędne klasy i pliki do obejrzenia jeśli mnie nie ściga :) – vee

+0

Wygląda na to, że [odcinek 287] (https://github.com/ryanb/railscasts-episodes/tree/master/episode-287) jest publiczny w co najmniej jednym z jego repozytoriów . –

3

Czy próbowałeś?

<% @some_condition_previusly_established_in_a_controller ? <div class="one">123</div> : <div class="two">something else</div> %> 
-2

Zawsze możesz przenieść logikę do kontrolera i pozostawić widok czysty (er).

Kontroler:

if @some_condition 
    @div_class = :one 
    @div_content = 123 
else 
    @div_class = :two 
    @div_content = 'something else' 
end 

Widok:

<div class="<%= @div_class %>"><%= @div_content %></div> 

lub przy użyciu pomocnika:

<%= content_tag :div, @div_content, class: @div_class %> 
3

Jeśli widok zawiera wiele znaczników i elementów HTML, można umieścić je w części i logika w modelu

Widok:

<%= render :partial => @model.status %> 

<%= render :partial => "file/path/#{@model.status}" %> # if your partial is in some different folder 

Jeśli stan jest jeden, wtedy byłoby renderować plik _one.html.erb

Jeśli to drugie, to byłoby to uczynić plik _two.html.erb automatycznie.

Model:

def status 
    if @some_condition 
     "one" 
    else 
     "two" 
    end 
end 
Powiązane problemy