wspólny widok dla kilku modeli

Dla dwóch modeli: Article oraz Ad chciałbym stworzyć wspólny partial templata prezentujący odpowiednio “wstęp do artykułu” lub “wstęp do ogłoszenia”.
Zależy mi na tym, żeby nie duplikować templata, który w praktyce będzie taki sam dla obu modeli.

wywołanie:

<%= render :partial => “common/lead”, :object => @article %>

<%= render :partial => “common/lead”, :object => @ad %>

W rezultacie w _lead.html.erb dostaję obiekt w zmiennej lead. Wszystko cacy, ale Ad i Article mają różne atrybuty, np lead.tags dla Article oraz lead.categories dla Ad.
Jak rozpoznać jakiego modelu obiektem jest lead wewnątrz partiala aby zależnie od modelu odwoływać się do różnych atrubytów?
Mógłbym przekazywać nazwę modelu do partiala ale może są lepsze metody, sprawdzone best practices dla takich przypadków?

lead.class

?

Czyli if-else w zależności od lead.class.name. Myślałem jeszcze o dodaniu jednakowych aliasów do atrybutów w modelach ale dla jednego templata nie ma raczej to sensu. Dzięki.

a ja zrobiłbym dwa osobne widoki- łatwiej się toto debuguje potem, łatwiej dodać nowe ficzery, mniej problemów - same plusy :wink:

[quote=Vayneyks]lead.class
?[/quote]
W Rubym bardziej się zaleca duck-typing i zorientowanie na interfejs (jakie metody udostępnia obiekt) niż sprawdzanie jego klasy (zwłaszcza że dzięki Object#extend klasa może być bardzo mylnym kryterium).
Znaczy, bardziej ruby-way byłby kod sprawdzający co też można zrobić z danym obiektem:

[code]if(lead.respond_to?(:tags))

render tags

elsif(lead.respond_to?(:categories))

render categories

end[/code]
Takie podejście ma jeszcze [co najmniej] dwie zalety:

  1. jeśli zamiast if-else zrobisz dwa ify, możesz “za darmo” dorzucić categories dla Article i tags dla Ad
  2. jeśli pojawi ci się trzecia klasa do pokazania tym samym widokiem, to działa bez dodatkowych interwencji

@krzyzak

Jeden znaczący minus: przy każdej zmianie trzeba wyedytować osobno każdy plik templata, a tego chciałbym uniknąć.
Szczególnie sporo tych zmian gdy większość aplikacji jest gotowa i dopracowuje się tylko widoki.

@Tomash

Idealne rozwiązanie, dzięki. Szczególnie z tą obsługą ewentualnych dodatkowych modeli.

Jeżeli używasz Ruby on Rails w wersji 3.1, możesz skorzystać z dziedziczenia szablonów. Tutaj masz przykład Ryana Batesa: http://railscasts.com/episodes/269-template-inheritance