mam np kontroler news ktory wyswietla newsy oraz np kontroler photos ktory wyswietla zdjecia
i teraz chcialbym zrobic kontroler np main ktory w swoim widoku bedzie wyswietlac newsy oraz zdjecia
w jaki sposob moge to zrobic , czy moge jakos wywolac te kontrolery w widoku kontrolera main ale tak zeby w kontrolerze main nie tworzyc zadnych zmiennych zwiazanych z tymi 2 kontrolerami
jezeli moglby ktos mi to wytlumaczyc jak to sie robi bylbym naprawde wdzieczny
Według mnie bardziej chodzi ci o wykorzystanie partials, tj. w momencie gdy robisz widok do wyświetlania news to część która ma być wspólna wrzucasz do partiala(takie pliczki zaczynające się od “_” np. _show.html.erb . Następnie w widoku do kontrolera main załączasz taki partial. Podobnie robisz w przypadku photo. http://guides.rubyonrails.org/layouts_and_rendering.html#using-partials
@phocke - musialem uzyc partiala stworzylem w news plik _list.erb i jest ok , tyle ze partiale znam ale generalnie nie znam jeszcze dobrze railsa wiec moze chcialem przekombinowac generalnie np w symfony kumple robia jakos tak ze np w widoku jakimkolwiek chca moga sobie uzyc w smarty include_component i ten kontroler w ktorego widoku to robia nie musi miec nawet chyba tego @news= News.find(:all) a tu u nas main musi to miec ,
chodzilo mi to czy da sie jakos w railsach i jesli tak to jak zrobic tak ze np tworze sobie kontroler main i w jego widoku index wykonuje sobie jakiegos includa czy cos i wykonuje mi sie kod z kontrolera newsa czy jakis widok ale w main nic nie musze robic ?? oo i to jest moje pytanie ?
no to skorzystaj z linka sebana, albo zrób coś co nie jest ładne i nie “rails way”
[code=ruby]#dajesz finda w partialu (to jest ta brzydka rzecz)
<% Photo.find(:all).each do |img| -%>
<% link_to “obrazek” do %>
<%= image_tag img.public_path %>
<% end %>
<% end -%>
#nie testowane, więc może sypnąć jakimś syntaxem albo coś #pozniej renderujesz partiala gdzie tam chcesz i od razu śmiga[/code]
Pewnie tak ok dzieki , wiec najlepsze rozwiazanie to te co podal seban ale to jeszcze jestem za kiepski pozdrawiam i dzieki za pomoc wracam do ksiazki od Ruby
pozdrawiam ( programowanie co raz bardziej mi sie podoba )
pewnie chodzi o tą część, bo to powinno być w kontrolerze a nie widoku[/quote]
Kontroler powinien wczytywać tylko jedną kolekcję, do tego tylko z modelu, który bezpośrednio obsługuje (@users w UsersController). Co więcej kontroler powinien ustawiać tylko jedną zmienną instancji (np. @user). Brzmi to rygorystycznie ale stosując się do tej reguły można tworzyć bardzo proste i łatwe w zmianie aplikacje.
Widoki mogą wyciągać dowolne dane z dwóch źródeł: z jedynej zmiennej instancji jaką ustawia kontroler (@user.photos) lub z PRZETESTOWANYCH metod klasy modelów (np. named scopes: Photos.all). Oczywiście ręczne użycie find() w widoku odpada.
Partial, który sam wyciąga dane z named scope można bez zmian użyć w wielu miejscach. Można go też bez problemu wrzucić w cache.
Z kolei jeśli trzymasz się kurczowo zasady, że wszystkie kolekcje wolno wczytywać tylko w kontrolerze to dodajesz sobie pracy. Musisz je wczytywać w każdym kontrolerze, którego widok chce użyć partiala (lub posłużyć się filtrem). I oczywiście to przetestować, w każdym kontrolerze. Tworzy się bałagan i duża, nikomu nie potrzebna zależność pomiędzy kontrolerem a partialem. No i nie da się tego już w prosty sposób cache’ować.
Podsumowując: zamień Photo.find(:all) na Photo.all i możesz tego swobodnie użyć w parialu.
Tzn. Photo.find(:all) vs Photo.all. Wiem, że Photo.all wygląda ładniej, nie ma nawiasów i może się wydawać, że nic tam dopisać nie można, ale prawie każdy wie, że i tak mogą tam dopisać Photo.all(:conditions => {:foo => “bar”}), albo w nowych Railsach Photo.where(:foo => “bar”).all.
W każdym razie oprócz wyglądu nie wydaje mi się, żeby zamiana find(:all) na all cokolwiek dodaład do aplikacji
Bragi, skąd się to wzięło? Zgodzę się że tak powinno być w 90% przypadków, ale jak masz DashboardController, który wyświetla artykuły, newsy i najnowsze komentarze obok siebie to dlaczego nie ustawiać 3 zmiennych instancyjnych? Trzeba wiedzieć kiedy zrobić wyjątek od reguły.