Najlepsze praktyki dotyczące szyn dla tego samego formularza na wielu stronach

Question

Zajmuję się tworzeniem strony internetowej Rails 2.3.1. W całej witrynie potrzebuję formularza do tworzenia postów na różnych stronach (strona główna, strona tworzenia postów, strona z listą wpisów, strona z komentarzami itp. - wystarczy powiedzieć, że ten formularz musi znajdować się na wielu stronach obsługiwanych przez wiele kontrolerów). Każda z tych stron wyświetla wiele innych informacji, które są pobierane w odpowiednim kontrolerze/akcie. Ex, strona główna zawiera listę 10 najnowszych wpisów, treść pobraną z bazy danych itp.

Przesunąłem więc formularz tworzenia postów do częściowej, i uwzględniłem to częściowe na wszystkich niezbędnych stronach. Zauważ, że formularz w częściowych testach POST do/pytania (które trasy do PostsController :: create - jest to zachowanie domyślne rails).

Problem, na który napotykam, to fakt, że formularz Posty nie jest poprawnie wypełniony, domyślnie PostsController :: create renderuj metodę pytania/new.html.erb, nawet jeśli formularz został przesłany ze strony głównej (/ home/index.html.erb).

Próbowałem zmienić formularz w częściowym, aby przesłać "submitting_controller" i "submining_action", a także w PostsController :: create, when @ post.save? == false, wyświetlam action => "../submitting_controller/submitting_action" (co jest nieco hackowskie, ale pozwala na renderowanie akcji z nie-PostScriptera).

Wydawało się, że działa dobrze na powierzchni. Niekompletna forma została wyświetlona w widoku, który przesłał go ze wszystkimi poprawnymi komunikatami @ post.errors, itp. Problemem było WSZYSTKIE inne dane na stronach, które się pojawiły, ponieważ rzeczywiste metody submitting_controller/submitting_action nie były wywoływane, tylko powiązany widok. (Remeber, zrobiłem render, który zachowuje obiekty instancji, a nie przekierowanie, które nie zachowuje obiektu instancji @post, który ma wszystkie komunikaty o błędach i przesłane wartości.)

O ile widzę, mam dwie opcje :

1) Czy mogę przechowywać obiekt @post w sesji, gdy @ post.save? kończy się niepowodzeniem w PostsController :: create, redirect_to submitting_controller/submitting_action, w tym momencie wyciągam obiekt @post z sesji i używam go do ponownego wypełnienia formularza/komunikatów o błędach. (O ile rozumiem, przechowywanie obiektów w sesji to ZŁE praktyki w szynach)

2) Potrafię przenieść całą logikę używaną do wyciągania danych z formularzy kreacji niezwiązanych z postów z różnych submitting_controller/submision_action, umieść go w ApplicationController, stwórz gigantyczną instrukcję switch w PostsController :: create dla submitting_controller/submitting_action i wywołaj metody w ApplicationController, aby pobrać wszystkie dodatkowe dane potrzebne do renderowania każdej strony.

Myśli o najlepszym sposobie zrobienia tego w Railsach?

Answer 1

Czy przypadkiem jest model Post w relacji belongs_to z każdym modelem, którego kontrolera użyjesz do renderowania formularza? Czy robisz jakieś specjalne przetwarzanie w kontrolerze Post poza Post.create(params[:post])?

Jeśli odpowiedziałeś "tak" na pierwsze pytanie, a nie "na drugie", możesz uzyskać minimalne zniekształcenie przez dodanie accepts_nested_attributes_for do każdego kontrolera, na którym użytkownik może utworzyć wpis.

Bez względu na to, Robertpostill ma rację, prawdopodobnie dlatego, gdy zaczyna się przeglądanie AJAX, aby po prostu zamienić sekcję strony. Jedynym problemem jest to, co zrobić, jeśli użytkownik ma wyłączony javascript. Osobiście lubię projektować dla sprawy nie javascript i dodawać metody wygody.

Co do myśli o tym, co uważasz za swoje dwie opcje,

1) Użyłem tej metody przechowywania płytką kopię obiektu w hash flash. Zachowywanie go w przekierowaniach. Może to jednak nie działać, biorąc pod uwagę zmienną naturę postów. Ponieważ możesz wysyłać tylko około 4K danych, i to zawiera inne informacje oprócz twojej płytkiej kopii.

2) Zobacz robertpostill za odpowiedź

Answer 2

Chodzi o to, że przejście od aktualizacji pełnej strony do aktualizacji sekcji strony za pomocą AJAX. Istnieje kilka rzeczy, które należy wziąć pod uwagę, ale najbardziej railsowym rozwiązaniem byłoby podzielenie odpowiedzi między odpowiedzią AJAX a zwykłą odpowiedzią HTML. Sprawdź this ONLamp article, this register article lub the awesome agile web development with rails book. Zasadniczo kontroler renderuje nowy element div zastępujący stary element div zawierający wynik przesłania częściowego.

W swoim pytaniu można wymienić dwa podejścia i tak spróbuję i dać kilka wskazówek na temat, dlaczego i dlaczego nie tutaj:

Opcja 1) opcja Ths nie jest tak źle z kilkoma ulepszeniami. Głównym usprawnieniem jest przechowywanie obiektu w postaci szeregowej w DB. Następnie po prostu przekazuj identyfikator ID serializowanego obiektu.Twoje zalety są takie, że dane sesji są utrwalane, więc odzyskiwanie sesji jest łatwiejsze, a twoja sesja pozostaje lekka. Wadą tego jest to, że posiadanie kubełka sesji w twoim DB będzie zanieczyszczać twoją aplikację i będziesz musiał pomyśleć o tym, jak wygasasz niewykorzystany cruft sesji z DB. Nigdy nie widziałem tego dobrze ...

Opcja 2) Eeek nie wewnątrz kontrolera application_! :) Poważnie, zachowaj to jako ostatnią deskę ratunku. Możesz jednak poprzeć rzeczy insde pomocnikami i uzyskać dostęp do tych metod wewnątrz kontrolerów i widoków. Jednak testowanie tych rzeczy nie jest takie proste, więc bądź ostrożny przed wyborem tej trasy. Instrukcje przełączania można zastąpić w aplikacjach OO odrobiną myślenia, na pewno w jego przypadku można użyć skrótów opcji, aby uzyskać railsy o pewnych sprytach dotyczących stanu aplikacji w momencie jej żądania.