Fluxul de aplicare Ruby on Rails

Când îți scrii propriile programe de la început până la sfârșit, este ușor de văzut Controlul debitului. Programul începe aici, există o buclă acolo, apelurile la metodă sunt aici, este vizibil. Dar într-o aplicație Rails, lucrurile nu sunt atât de simple. Cu un cadru de orice fel, renunțați la controlul unor astfel de lucruri precum „flux” în favoarea unui mod mai rapid sau mai simplu de a face sarcini complexe. În cazul Ruby on Rails, controlul fluxului este gestionat în spatele scenei, iar tot ce ai mai rămas este (mai mult sau mai puțin) o colecție de modele, vizualizări și controlere.

La baza oricărei aplicații web se află HTTP. HTTP este protocolul de rețea pe care browserul web îl folosește pentru a vorbi cu un server web. De aici provin termeni precum „cerere”, „GET” și „POST”, sunt vocabularul de bază al acestui protocol. Cu toate acestea, din moment ce Rails este o abstractizare a acestui lucru, nu vom petrece mult timp vorbind despre asta.

Când deschideți o pagină web, faceți clic pe un link sau trimiteți un formular într-un browser web, browserul se va conecta la un server web prin TCP / IP. Browserul trimite apoi serverului o „solicitare”, gândiți-vă la acesta ca la un formular de mail pe care îl completează browserul cerând informații pe o anumită pagină. Serverul trimite în cele din urmă browser-ului web un „răspuns”. Totuși, Ruby on Rails nu este serverul web, serverul web poate fi orice de la Webrick (ceea ce se întâmplă de obicei atunci când pornești de la un server Rails

Unul dintre primele lucruri pe care le face o aplicație Rails cu o solicitare este să o trimiteți prin router. Fiecare solicitare are o adresă URL, aceasta apare în bara de adrese a unui browser web. Routerul este ceea ce determină ce trebuie făcut cu URL-ul respectiv, dacă URL-ul are sens și dacă URL-ul conține parametri. Routerul este configurat în config / routes.rb.

Mai întâi, știți că scopul final al routerului este de a potrivi o adresă URL cu un controler și acțiune (mai multe despre acestea mai târziu). Și având în vedere că majoritatea aplicațiilor Rails sunt RESTful, iar lucrurile din aplicațiile RESTful sunt reprezentate folosind resurse, veți vedea linii precum resurse: postări în aplicații tipice Rails. Aceasta se potrivește cu adresele URL de genul /posts/7/edit cu controlerul Posts, Editați | × acțiune pe Post cu ID-ul 7. Routerul decide doar unde se duc cererile. Deci blocul nostru [Rails] poate fi extins puțin.

Acum, când routerul a decis ce controlor să trimită cererea și ce acțiuni asupra acelui controler, îl trimite. Un controler este un grup de acțiuni conexe toate grupate într-o clasă. De exemplu, într-un blog, toate codurile pentru vizualizarea, crearea, actualizarea și ștergerea postărilor de blog sunt grupate într-un controler numit „Postare”. Acțiunile sunt doar normale metode din această clasă. Controlerele sunt amplasate în app / controlere.

Deci, să zicem că browserul web a trimis o solicitare pentru /posts/42. Router-ul decide că aceasta se referă la Post controler, dispozitivul spectacol metoda și ID-ul postării de afișat este 42, deci apelează la spectacol metoda cu acest parametru. spectacol metoda nu este responsabilă pentru utilizarea modelului pentru preluarea datelor și utilizarea vizualizării pentru a crea rezultatul. Deci, blocul nostru extins [Rails] este acum:

Modelul este atât cel mai simplu de înțeles și cel mai dificil de implementat. Modelul este responsabil pentru interacțiunea cu baza de date. Cel mai simplu mod de a-l explica este modelul este un set simplu de apeluri de metodă care returnează obiecte simple Ruby care gestionează toate interacțiunile (citește și scrie) din baza de date. Prin urmare, urmând exemplul blogului, API-ul pe care controlorul îl va folosi pentru a prelua date folosind modelul va arăta ceva similar Post.find (params [: id]). params este ceea ce routerul analizat de pe URL, Post este modelul. Acest lucru face interogări SQL sau face orice este necesar pentru a prelua postarea pe blog. Modelele sunt amplasate în app / modele.

Este important de reținut că nu toate acțiunile trebuie să utilizeze un model. Interacțiunea cu modelul este necesară numai atunci când datele trebuie să fie încărcate din baza de date sau salvate în baza de date. Ca atare, vom pune după el un semn de întrebare în mica noastră diagramă de fluxuri.

În cele din urmă, este timpul să începeți să generați niște HTML. HTML nu este gestionat de controler în sine și nici nu este gestionat de model. Ideea utilizării unui cadru MVC este să compartimentăm totul. Operațiunile bazei de date rămân în modul, generarea HTML rămâne în vizor, iar controlerul (numit de router) le numește pe amândouă.

HTML este în mod normal generat cu Ruby încorporat. Dacă sunteți familiarizat cu PHP, adică un fișier HTML cu cod PHP încorporat în acesta, atunci Ruby încorporat va fi foarte familiar. Aceste vederi sunt situate în app / vizualizăriși un controler va apela unul dintre ei pentru a genera ieșirea și a o trimite înapoi la serverul web. Orice date preluate de controler folosind modelul vor fi în general stocate într-un variabila de instanta care, datorită unor magii Ruby, vor fi disponibile ca variabile de instanță din interior. De asemenea, Ruby încorporat nu trebuie să genereze HTML, poate genera orice tip de text. Veți vedea acest lucru atunci când generați XML pentru RSS, JSON etc.

Această ieșire este trimisă înapoi către serverul web, care o trimite înapoi la browserul web, care finalizează procesul.