Mam następującą sytuację. W aplikacji mam model Car i jeden z jego atrybutów to reg_number (numer rejestracyjny). Generalnie w CarsController są wszystkie restowe akcje. Ale potrzebuję oddzielny formularz do update’u numeru rejestracyjnego (takie założenie w projekcie).
Generalnie mogę dodać akcje edit_reg_number i update_reg_number w CarsController. Ale ponieważ lubię mieć w miarę wszystko poukładane i nie mieć za dużo w jednej klasie, więc zastnawiam się, czy nie lepiej stworzyć RegNumbersController i tam mieć po prostu edit i update. Wygląda trochę czyściej ale w sumie nie wiem czy to nie jest pewnego rodzaju overkill lub niepotrzebne motanie?
No też właśnie mi się tak wydawało. Zadałem przed chwilą takie samo pytanie na #rubyonrails i ktoś odpowiedział: “Po co tworzyć nowy kontroler jeżeli RegNumber to nie jest oddzielny model - lepiej dodać akcję”.
Ale ponieważ byłem bardziej przekonany do wersji z 2 kontrolerami i zasobami to powtórzyłem pytanie tutaj - jak widać słusznie
A nie mógłbyś tego puścić przez update z CarsController? Wtedy wystarczyłoby dodać nową akcję typu edit albo jakoś zedytować oryginalną akcję edit z widokiem.
Generalnie mógłbym, ale tam jest trochę więcej motania przy tej akcji update’u reg_numbera wiec wole pozostac przy dodatkowej akcji update.
Ale generalnie w sumie tez ciekawe pytanie: Co jezeli faktycznie bym tak zrobil to jako jedna akcja update i by sie model nie zwalidowal - jak decydujecie ktory template zrenderowac - na podstawie referrera, czy dodajecie sobie jakis hidden field do formularza czy jeszcze jakos inaczej?
Masz sobie model który ma maszynę stanów i możesz go zaakceptować lub odrzucić co już jest zaimplementowane w edit/update.
Chcesz też mieć możliwość wykonania tej akcji z poziomu listy (index) poprzez linka. Zrobiłbyś nowy kontroler by obsłużyć 2 akcje approve/reject, który musiałby mieć dokładnie tą samą logikę znajdowania obiektu i sprawdzania praw dostępu użytkownika do ich wykonania ? Ja zostałem przy jednym z 2 akcjami więcej…
@paneq, akurat tutaj ja bym zrobił. To są akcje które wprowadzają jakieś zmiany w danych, wypada je obsłużyć czymś innym niż GETem. Ja bym stworzył nowy zagnieżdżony zasób i obsłużył akcjami create oraz destroy.
Ja nie mam nic przeciwko nawet wielu własnym akcjom w jednym kontrolerze, pod warunkiem że służą do pobierania danych w jakiejś określonej formie, a nie ich modyfikacji.
link z :method => :post powoduje, że dla railsów nie idą getem. I jak byś nazwał ten zagnieżdzony zasób ? :decision ? Przecież te akcje nie robią nic innego jak to samo co akcja :update więc jaki jest sens tworzyć nowy kontroler ? Jaka korzyść ? I dlaczego uważasz że fakt, że chce wygodnie coś akceptować bez przechodzenia do widoku edit implikuje konieczność stworzenia nowego zasobu skoro moim zdaniem nie mamy tutaj materialnie do czynienia z niczym nowym. To jest dla mnie wskazówka by stworzyć jednak akcje. ( trochę filozoficzna dysputa )
Nie, no jasne, zgadzam się. Z tym że działanie po akcji update może być domyślnie inne niż po kliknięciu tego przycisku. Raczej łatwo sobie wyobrazić że po kliknięciu “Accept” chcesz pozostać na bieżącej stronie, a po akcji “update” byś przekierowany do zasobu… Sprawa jest OK jak już jesteś w danym zasobie, ale jak jesteś w widoku listy i tam masz linki do zmiany stanu? Albo, jak chcesz obsłużyć to AJAXem, w ogóle bez opuszczania strony? Bez nowego kontrolera w takich sytuacjach robisz “ifa” w widoku. Kiedyś będziesz potrzebować znowu kilku akcji które z powodzeniem możesz wcisnąć w “update”, ale możesz potrzebować jeszcze innego przekierowania albo czegoś do wyrenderowania… i jesteś na prostej drodze do kodu spaghetti w swoich pięknych widokach lub akcji “update”.
Nie zrozumiałem za bardzo twojej wiadomości.
W akcji index na liście oprócz linka do :edit daje jescze link do akcji :approve i :reject, które po wykonaniu robią redirect z powrotem na listę. W czym problem? Nie mam żadnych if’ów na widoku odnośnie tego rozwiązania.
Poniekąd robią tylko sa skrótem. Na formatce edit wybierasz decyzję i możesz zostawić wiadomość wnioskującemu i widzisz więcej danych. A :approve i :reject są takim skrótem myślowym “nie muszę tam wchodzić i tego wszystkiego oglądać by podjąć decyzję, po prostu zatwierdź to”. 2 scieżki prowadzą do jednakowych rezultatów. Chciałem tylko pokazać jakiś (moim zdaniem sensowny) kontrprzykład dla wspomnianej tutaj zasady kciuka.
