Amikor elejétől a végéig saját programokat írsz, ez könnyen látható áramlásvezérlés. A program itt indul, van egy hurok, itt vannak módhívások, ez mind látható. De a Rails alkalmazásban a dolgok nem olyan egyszerűek. Bármilyen keretrendszerrel lemond az olyan dolgok ellenőrzéséről, mint például az „áramlás” az összetett feladatok gyorsabb vagy egyszerűbb végrehajtása érdekében. A Ruby on Rails esetében az áramlásszabályozást mind a színfalak mögött kezelik, és mindössze (többé-kevésbé) modell, nézet és vezérlők gyűjteménye marad.
Minden webes alkalmazás középpontjában a HTTP. A HTTP az a hálózati protokoll, amelyet az Ön böngészője használ a webkiszolgálóval való beszélgetéshez. Innen származnak olyan kifejezések, mint a "kérés", "GET" és "POST", és ezek a protokoll alapvető szókincsei. Mivel azonban a Rails ennek absztrakciója, nem fogunk sok időt erről beszélni.
Amikor megnyit egy weboldalt, kattintson egy linkre, vagy küldjön be egy űrlapot egy böngészőben, a böngésző TCP / IP-n keresztül kapcsolódik a webszerverhez. A böngésző ezután elküldi a szervernek egy "kérést", és úgy gondolja, mint egy e-mail formában, amelyet a böngésző kitölti az információk kérésével egy adott oldalon. A szerver végül "választ" küld a böngészőnek. A Ruby on Rails azonban nem a webszerver, a webszerver bármi lehet Webricktől (ami általában akkor fordul elő, amikor a Rails szervert indítja az
parancs sor) az Apache HTTPD-hez (annak a webszervernek a számára, amely a weben a legtöbbet hatalmazza). A webszerver csak egy segítő, elviszi a kérést és átadja a Rails alkalmazásnak, amely generálja a választ és továbbítja, visszatér a szerverhez, amely viszont visszajuttatja a ügyfél. Tehát az eddigi áramlás:Az egyik első lépés, amelyet a Rails alkalmazás kéréssel tesz, az, hogy elküldi azt a routerön keresztül. Minden kérésnek van URL-je, ez jelenik meg a böngésző címsorában. Az útválasztó határozza meg, hogy mit kell tenni az URL-rel, ha az URL-nek van értelme és ha az URL tartalmaz paramétereket. Az útválasztó be van állítva config / routes.rb.
Először is tudd, hogy az útválasztó végső célja az, hogy egy URL-t egy vezérlővel és egy művelettel párosítson (ezekről később bővebben). Mivel a legtöbb Rails alkalmazás RESTful, és a RESTful alkalmazásokban a források felhasználásával ábrázolják a dolgokat, látni fogják a hasonló sorokat források: hozzászólások tipikus Rails alkalmazásokban. Ez megegyezik az URL-ekkel, mint például /posts/7/edit a Posts vezérlővel, a szerkesztés akció a 7-es azonosítójú postán. Az útválasztó csak eldönti, hová indul a kérés. Tehát a [Rails] blokk kibővíthető.
Most, hogy az útválasztó úgy döntött, hogy melyik vezérlőnek küldje el a kérést, és hogy melyik művelettel vezérli azt, akkor továbbítja. A Vezérlő egy kapcsolódó műveletek csoportja, amelyek összeszerelve vannak egy osztályban. Például egy blogban a blogbejegyzések megtekintéséhez, létrehozásához, frissítéséhez és törléséhez szükséges összes kódot a „Feladás” vezérlő vezérli. A műveletek csak normálisak mód ebbe az osztályba. A vezérlők itt találhatók: app / vezérlők.
Tegyük fel, hogy a webböngésző kérést küldött erre /posts/42. A router úgy dönt, hogy ez a posta vezérlő, a előadás módszer és a megjelenítendő üzenet azonosítója 42, így hívja a előadás módszer ezzel a paraméterrel. Az előadás A módszer nem felelős azért, hogy a modellt használja az adatok beolvasásához, és a nézetet használja a kimenet létrehozásához. Tehát kibővített [Rails] blokkunk most:
A modell egyszerûen megérthetõ és legnehezebben megvalósítható. A modell felelős az adatbázis használatával. A modell legegyszerűbb magyarázata a módszerhívások egyszerű halmaza, amely egyszerű Ruby objektumokat ad vissza, amelyek az adatbázisban minden interakciót (olvasást és írást) kezelnek. Tehát a blog példáját követve az a kezelőfelület, amelyet a vezérlő fog használni az adatok lekérdezéséhez a modell segítségével, valami hasonlónak fog kinézni Post.find (params [: id]). Az params az, amit a router az URL-ből elemez, a Post a modell. Ez SQL lekérdezéseket tesz, vagy megtesz minden, ami a blogbejegyzés lekéréséhez szükséges. A modellek székhelye: app / modellek.
Fontos megjegyezni, hogy nem minden tevékenységnek kell modellt használni. A modellel való kölcsönhatás csak akkor szükséges, ha az adatokat ki kell tölteni az adatbázisból vagy el kell tárolni az adatbázisba. Mint ilyen, kérdőjelet helyezünk utána a kis folyamatábránkba.
Végül itt az ideje elkezdeni generálni néhány HTML-t. A HTML-t nem a vezérlő kezeli, hanem a modell sem. Az MVC keretrendszer használatának lényege, hogy mindent elkülönítsen. Az adatbázis műveletek módban maradnak, a HTML generáció a nézetben marad, és a vezérlő (amelyet az útválasztó hív) mindkettőt meghívja.
A HTML általában beágyazott Ruby használatával készül. Ha ismeri a PHP-t, azaz egy HTML-fájlt, amelybe be van ágyazva a PHP-kód, akkor a beágyazott Ruby nagyon ismerős lesz. Ezek a nézetek a app / views, és a vezérlő felhívja az egyiket a kimenet előállításához, és visszajuttatja a webkiszolgálóra. A modell használatával a vezérlő által lekérdezett adatokat általában egy példány változó amely néhány Ruby varázslatnak köszönhetően példányváltozókként lesz elérhető a nézetben. A beágyazott Ruby-nak nem kell HTML-t generálnia, bármilyen típusú szöveget képes generálni. Ezt akkor láthatja, amikor XML-t generál RSS, JSON stb. Számára.
Ezt a kimenetet visszajuttatjuk a webszerverhez, amely visszajuttatja a webböngészőhöz, amely befejezi a folyamatot.