Kiedy piszesz własne programy od początku do końca, łatwo to zobaczyć Kontrola przepływu. Program zaczyna się tutaj, jest tam pętla, wywołania metod są tutaj, wszystko jest widoczne. Ale w aplikacji Railsowe rzeczy nie są takie proste. Dzięki wszelkiego rodzaju ramom rezygnujesz z kontroli takich rzeczy jak „przepływ” na rzecz szybszego lub prostszego sposobu wykonywania skomplikowanych zadań. W przypadku Ruby on Rails kontrola przepływu jest obsługiwana za kulisami, a wszystko, co pozostaje, to (mniej więcej) kolekcja modeli, widoków i kontrolerów.
Podstawą każdej aplikacji internetowej jest HTTP. HTTP jest protokołem sieciowym używanym przez przeglądarkę internetową do komunikowania się z serwerem internetowym. Stąd pochodzą terminy takie jak „żądanie”, „GET” i „POST”, są podstawowym słownictwem tego protokołu. Ponieważ jednak Rails jest abstrakcją tego, nie będziemy dużo rozmawiać o tym.
Po otwarciu strony internetowej kliknij link lub prześlij formularz w przeglądarce internetowej, przeglądarka połączy się z serwerem internetowym za pośrednictwem protokołu TCP / IP. Przeglądarka następnie wysyła do serwera „żądanie”, pomyśl o tym jak o formie wiadomości e-mail, którą przeglądarka wypełnia, prosząc o informacje na określonej stronie. Serwer ostatecznie wysyła do przeglądarki internetowej „odpowiedź”. Ruby on Rails nie jest jednak serwerem WWW, serwer WWW może być czymkolwiek innym niż Webrick (co zwykle dzieje się po uruchomieniu serwera Railsowego
wiersz poleceń) do Apache HTTPD (serwer sieciowy, który obsługuje większość sieci). Serwer WWW jest tylko facylitatorem, bierze prośbę i przekazuje ją twojej aplikacji Rails, który generuje odpowiedź i przekazuje z powrotem na serwer, który z kolei przesyła ją z powrotem do klient. Dotychczasowy przepływ to:Jedną z pierwszych rzeczy, które aplikacja Railsów robi z żądaniem, jest wysłanie go przez router. Każde żądanie ma adres URL, to pojawia się na pasku adresu przeglądarki internetowej. Router określa, co należy zrobić z tym adresem URL, jeśli adres URL ma sens i czy adres URL zawiera jakieś parametry. Router jest skonfigurowany w config / trasy.rb.
Po pierwsze, wiedz, że ostatecznym celem routera jest dopasowanie adresu URL do kontrolera i akcji (więcej na ten temat później). A ponieważ większość aplikacji Railsowych jest RESTful, a rzeczy w RESTful są reprezentowane przy użyciu zasobów, zobaczysz takie linie zasoby: posty w typowych aplikacjach Railsowych. To pasuje do adresów URL takich jak /posts/7/edit z kontrolerem Postów, edytować akcja na postu z identyfikatorem 7. Router po prostu decyduje, dokąd trafiają żądania. Tak więc nasz blok [Rails] może zostać nieco rozszerzony.
Teraz, gdy router zdecydował, do którego kontrolera wysłać zapytanie i do jakiej akcji na tym kontrolerze, wysyła je dalej. Kontroler to grupa powiązanych działań, wszystkie połączone w jedną klasę. Na przykład w blogu cały kod do przeglądania, tworzenia, aktualizowania i usuwania postów na blogu jest zgrupowany w kontrolerze o nazwie „Publikuj”. Działania są po prostu normalne metody z tej klasy. Kontrolery znajdują się w aplikacja / kontrolery.
Powiedzmy, że przeglądarka internetowa wysłała żądanie /posts/42. Router decyduje, że odnosi się to do Poczta kontroler pokazać metoda i identyfikator wpisu do wyświetlenia to 42, więc nazywa się pokazać metoda z tym parametrem. The pokazać Metoda nie ponosi odpowiedzialności za użycie modelu do pobrania danych i użycie widoku do utworzenia danych wyjściowych. Tak więc nasz rozszerzony blok [Rails] jest teraz:
Model jest zarówno najprostszy do zrozumienia, jak i najtrudniejszy do wdrożenia. Model odpowiada za interakcję z bazą danych. Najprostszym sposobem na wyjaśnienie tego jest model to prosty zestaw wywołań metod, które zwracają proste obiekty Ruby, które obsługują wszystkie interakcje (odczyty i zapisy) z bazy danych. Zatem zgodnie z przykładem bloga interfejs API, którego kontroler będzie używał do pobierania danych za pomocą modelu, będzie wyglądał podobnie Post.find (params [: id]). The parametry jest tym, co router przeanalizował z adresu URL, Post jest modelem. To powoduje zapytania SQL lub robi wszystko, co jest potrzebne do pobrania posta na blogu. Modele znajdują się w aplikacja / modele.
Należy zauważyć, że nie wszystkie działania wymagają użycia modelu. Interakcja z modelem jest wymagana tylko wtedy, gdy dane muszą zostać załadowane z bazy danych lub zapisane w bazie danych. W związku z tym umieścimy po nim znak zapytania w naszym małym schemacie blokowym.
Wreszcie nadszedł czas, aby zacząć generować trochę HTML. HTML nie jest obsługiwany przez sam kontroler ani nie jest obsługiwany przez model. Celem zastosowania frameworka MVC jest podzielenie wszystkiego na części. Operacje na bazie danych pozostają w trybie, generowanie HTML pozostaje w widoku, a kontroler (wywoływany przez router) wywołuje je oba.
HTML jest zwykle generowany przy użyciu osadzonego Ruby. Jeśli znasz PHP, to znaczy plik HTML z osadzonym w nim kodem PHP, to osadzony Ruby będzie bardzo znajomy. Te widoki znajdują się w aplikacja / widoki, a kontroler wywoła jedno z nich, aby wygenerować dane wyjściowe i odesłać je z powrotem do serwera WWW. Wszelkie dane pobrane przez kontrolera korzystającego z modelu będą na ogół przechowywane w pliku zmienna instancji które, dzięki pewnej magii Ruby, będą dostępne jako zmienne instancji w widoku. Ponadto osadzony Ruby nie musi generować HTML, może generować dowolny rodzaj tekstu. Zobaczysz to podczas generowania XML dla RSS, JSON itp.
Dane wyjściowe są wysyłane z powrotem do serwera WWW, który wysyła je z powrotem do przeglądarki internetowej, która kończy proces.