Witam. Powracam w swym drugim watku (tak jak obiecywalem ;] )
Pytanie na dzisiaj jest nastepujace. Jak moge przerobic ponizszy kod , tak aby pokazywal mi skrypt wszystkie artykuly z eventow , a nie tylko po jakims tam filtrowaniu. W rezultacie koncowym chcialbym miec cala liste wraz z linkami do wszystkich “eventow” Pozdrawiam i dziekuje z gory za sugestie Btw. czas mnie nagli
[code]
<%= flash[:notice] if flash[:notice] %>
<% if !params[:id] %>
<% @places = all.find(:all, :conditions => {:active => true, :language => @language}, :order => “name ASC”)
for place in @places %>
Spojrz na ta linijke @events = Event.find(:all, :conditions => {:place_id => params[:id], :language => @language}, :order => “date, hour, minute ASC”)
Ona pobiera wszystkie eventy ktore naleza do danego miejsca(place_id) oraz ze wzgledu na jakis jezyk. Wszystko sortowane jest po dacie.
Przerob to zapytanie tak jak chcesz, mozesz zostawic @events = Event.find(:all)
Swoja droga dobrze by bylo wyniesc to do kontrolera.
Jezeli chodzi o czysta prezentacje linkow do eventów
<% for event in @events %>
<% end %>
Nie chciałbym zbyt mocno demotywować, ale wydaje mi się że pisanie php w ruby jest chyba trudniejsze niż w php (chociaż głowy nie dam). Z szybkich konstruktywnych propozycji: tak jak pisze lis2: uciekaj z całą logiką do kontrolerów, tworzenie zmiennych w widoku nie zawsze jest zalecaną techniką …
Ja, podobnie jak gruby, nie chcę demotywować, mam nadzieję, że coś wyjaśnię. Zasadniczo framework taki jak Rails, rozwiązuje za nas wiele typowych problemów, w szczególności po to, byśmy nie musieli zbyt często stosować w widoku paskudenj instrukcji warunkowej. Otóż
if params[:id] … else … end - to powinny być zupełnie odrębne widoki i akcje (nie wiem, czy nawet nie kontrolery). W jednej miałbyś tylko logikę dla events, w drugiej, tylko dla places.
if @language … else … end - do tego służy wbudowany w Railsy mechanizm lokalizacji aplikacji.
Swoja drogą zmienne l1, l2, l3… to coś co jest największym koszmarem informatycznym. Jako takim ulepszeniem byłoby chociażby zastosowanie tablicy fields = ["Nazwa: ", “Data :”, "Miejsce: "…], dużo lepiej byłoby gdbyby była to tablica asocjacyjna fields = {:name => "Nazwa: ", :date => "Data: ", …}. Oczwiście zdecydowanie nie powinno się to pojawić w widoku, a poza tym patrz punkt poprzedni.
Place.find(event.place_id).name - o asocjacjach czytałeś? Jeśli zdefiniujesz sobie w Event belongs_to Place, to będziesz mógł napisać po prostu envent.place.name. Podobnie ze związkiem Artist i Event
if !event.minute … end - albo wrzuć to do helpera, albo do modelu event (choć to ostatnie nie jest to dokońca zgodne z MVC).
Ten drugi blok if @language, to już jest majstersztyk. Kod wydaje się identyczny z dokładnością do tego, że mamy inne obrazki rezerwuj vs. rezerwuj2, etc. Czy nie prościej byłoby zrobić obrazki o nazwach rezwerwuj_pl.png, rezerwuj_en.png a w helperze (nie w widoku!) odpowiednio uzupełniać ich nazwę na podstawie inf. o języku, np. “rezerwuj_#{@language}.png”?
To już nie związane z Railsami, ale ogólnie HTMLem - trzymanie w kodzie styli obiektów, albo używanie klas o nazwach “p_e_h_t_td”, to jest dla mnie prawdziwy kosmos.
Jeśli nie masz nic przeciwko, wezmę ten kod i pokaże na zajeciach, żeby zilustrować sposób w jaki nie powinno się programować w Railsach.
Inna sprawa, ze chyba nie da sie po prostu usiasc i zaczac klepac w rails. Mozna znac 100 jezykow programowania, ale i trzeba poczytac o idei, strukturze itd… Wyjatkiem moze jest gdy ktos zna jakies framework php z wzorcem MVC, chociaz tutaj ciezko mi sie wypowiadac, bo ja uczylem sie rails od podstaw
W każdym języku i frameworku jest jakiś zestaw konwencji i dobrych praktyk
Co do rails, to się nie przejmuj, większość osób zaczyna od wielkich kontrolerów, przeładowanych logiką widoków i pustych modelach. Czytaj kod, rails best practices itp. Dużo tego w sieci jest