Parę razy już się tu na forum natknąłem na stwierdzenia, że request.post? to zło, że od tego są routes itp. Ale w sumie chciałbym wyjaśnienie (i to niereligijne!) dlaczego. Co jest złego w połączeniu standardowych akcji new i create (edit i update) w jedną, podzieloną na dwie części za pomocą if request.post? ? Generuje to jakieś realne utrudnienia? Błędy? Czy po prostu zdaniem niektórych brzydko wygląda?
Jeszcze może dodam dlaczego moim zdaniem to wygląda dobrze
Chociaż jedna z tych akcji zajmuje się operacjami na bazie danych, a druga zwykle tylko wyświetlaniem formularza, to z innej strony na to patrząc zajmują się jednak tym samym (dodawaniem/edytowaniem instancji danego modelu).
Nie powoduje to efektu znanego ze standardowych aplikacji railsowych, że czasem formularz edycji jest pod /blabla/69/edit, a czasem pod /blabla/69/update, bo były błędy walidacji
Nie ma chyba (przynajmniej ja nie umiem sobie wyobrazić) sytuacji, w której jakiś użytkownik miałby mieć dostęp do akcji edit, a nie mieć do update albo odwrotnie.
Zamiast miliona akcji w kontrolerze, można mieć tylko 500k
Kwestia konwencji i tyle. Ja osobiście nie widzę nic złego w obsłudze tego w 1 akcji i sprawdzaniu request.post?. Chociaż jeśli robisz RESTowo to łatwiej jest jednak nie kombinować tylko robić tak jak railsy każą.
W teorii chyba nie ma w tym nic złego, tylko praktyka pokazuje, że akcje kontrolerów mają tendencję do rozrastania się (dlatego już na początku warto je rozdzielić). Chyba po prostu tylko tyle, że lepiej mieć więcej prostych metod niż mniejszą liczbę ale skomplikowanych metod, przy czym fajnie jak dana metoda robi tylko 1 rzecz a nie 5 różnych rzeczy (łatwiej ją zrozumieć czy przetestować). Kwestia gustu i pisania przejrzystego kodu.
wbrew pozorom takie rozbicie powoduje uproszczenie, a nie utrudnienie pisania kodu. Moim zdaniem jest wiele konwencji, do których trzeba poprostu dorosnąć, do których dochodzi się po większej lub mniejszej liczbie linii kodu/projektów. Ja również zaczynałem od tego, że REST jest dla lam, w końcu ja wiem lepiej jak to powinno wyglądać… tak samo z testowaniem, mvc, oop i milionem innych rzeczy. trzymanie się konwencji poprostu strasznie ułatwia pracę- zwłaszcza zespołową, gdzie wynikowy kod jest spójny.
Użycie request.post? nie jest “evil” tylko “stupid” :)[/quote]
To w takim razie dlaczego akcja create tworzy i wyświetla (w przypadku nieudanej próby zapisu) to samo co akcja new?
Natomiast nie wspomniałem, że chodzi mi o sytuacje, w których użycie typowego railsowego RESTa jest niemożliwe/nienaturalne, jak choćby metoda typu add_photo, dodająca zdjęcie do modelu (przy czym zdjęcie też jest modelem). add_photo, create_photo, edit_photo, update_photo? Jak dla mnie trochę overkill.
a czemu nie dodawać/edytować zdjęcia razem z modelem? W sensie - jak jest podane zdjęcie w formularzu, to dodaj/edytuj, jak nie, to nie rób z nim nic? Popatrz na przykład Paperclipa - tam to jest dokładnie tak rozwiązane, i da się rozwiązać RESTowo. Naturalnie.
Tylko dlatego, że redirect do new (preferowany, najczystszy, najbardziej intuicyjny) wymagałby głupich akrobacji z utrzymaniem aktualnych pól w rekordzie.
Chociaż to w sumie jest dobry pomysł na plugin/gema – przytrzymać te dane we flash!
REST jest fajny, ale jak wszystko, najlepiej stosować z umiarem. Czasami warto złamać niektóre zasady jeżeli mówimy tutaj o prostej akcji.
Ogólnie nie lubię takiego mieszania w akcjach new/create/edit/update, ale coś w stylu add_photo jestem w stanie zrozumieć - przesadzanie z RESTem też nie jest dobre.
bo REST jest odpowiedzią na większość problemów, ale napewno nie na wszystkie.
Np: Osobiście wolę messages_controller z akcjami inbox i outbox zamiast REST way: inboxes_controller z akcja index i show i outboxes_controller z akcja index i show
Natomiast przekonanie się, że REST jest odpowiedzą na większość problemów na początku developmentu można przyjąć na wiarę(“mądrzejsi ode mnie tak mówią, więc coś w tym musi być”) albo odrzucić to, i z biegiem czasu do tego dojrzeć.
Inbox i outbox to dwa różne widoki listy modeli Message. Dobrym rozwiązaniem będzie tu napisanie messages#index tak, żeby umiała rozróżnić widoki inbox i outbox. Następnie tą samą akcję podpinasz przez routes do dwóch różnych URLi. Masz prosty kontroler, proste routes i wszystko zbudowane w oparciu o REST.
