Wanneer u van begin tot eind uw eigen programma's schrijft, is het gemakkelijk te zien stroomregeling. Het programma begint hier, er is een lus, methodeaanroepen zijn hier, het is allemaal zichtbaar. Maar in een Rails-applicatie is het niet zo eenvoudig. Met een raamwerk van welke aard dan ook, geeft u de controle over zaken als "flow" op ten gunste van een snellere of eenvoudigere manier om complexe taken uit te voeren. In het geval van Ruby on Rails wordt de flow control allemaal achter de schermen afgehandeld en blijft er (min of meer) een verzameling modellen, view en controllers over.
De kern van elke webtoepassing is HTTP. HTTP is het netwerkprotocol dat uw webbrowser gebruikt om met een webserver te praten. Hier komen termen als "request", "GET" en "POST" vandaan, ze vormen de basiswoordenschat van dit protocol. Aangezien Rails hier een abstractie van is, zullen we er niet veel tijd aan besteden om erover te praten.
Wanneer u een webpagina opent, op een link klikt of een formulier in een webbrowser indient, maakt de browser verbinding met een webserver via TCP / IP. De browser verzendt vervolgens de server een "verzoek", en ziet het als een mail-in-formulier dat de browser invult om informatie op een bepaalde pagina te vragen. De server stuurt de webbrowser uiteindelijk een 'reactie'. Ruby on Rails is echter niet de webserver, de webserver kan van alles zijn van Webrick (wat meestal gebeurt wanneer u een Rails-server start) de
opdrachtregel) naar Apache HTTPD (de webserver die het grootste deel van het web aanstuurt). De webserver is slechts een facilitator, hij neemt het verzoek aan en overhandigt het aan uw Rails-applicatie, die het antwoord genereert en doorgeeft is terug naar de server, die het op zijn beurt terugstuurt naar de cliënt. Dus de stroom tot nu toe is:Een van de eerste dingen die een Rails-applicatie met een verzoek doet, is deze via de router verzenden. Elk verzoek heeft een URL, dit verschijnt in de adresbalk van een webbrowser. De router bepaalt wat er met die URL moet worden gedaan, of de URL zinvol is en of de URL parameters bevat. De router is geconfigureerd in config / routes.rb.
Weet eerst dat het uiteindelijke doel van de router is om een URL te matchen met een controller en actie (hierover later meer). En aangezien de meeste Rails-applicaties RESTful zijn en dingen in RESTful-applicaties worden weergegeven met bronnen, zie je regels zoals bronnen: berichten in typische Rails-toepassingen. Dit komt overeen met URL's zoals /posts/7/edit met de Posts-controller, de Bewerk actie op de post met de ID van 7. De router beslist gewoon waar de verzoeken naartoe gaan. Dus ons [Rails] blok kan wat uitgebreid worden.
Nu de router heeft besloten naar welke controller het verzoek moet worden verzonden en naar welke actie op die controller, stuurt hij het door. Een controller is een groep gerelateerde acties die allemaal samen in een klas zijn gebundeld. In een blog wordt bijvoorbeeld alle code voor het bekijken, maken, bijwerken en verwijderen van blogposts gebundeld in een controller genaamd "Post". De acties zijn gewoon normaal methoden van deze klasse. Controllers bevinden zich in app / controllers.
Dus laten we zeggen dat de webbrowser een verzoek heeft verzonden /posts/42. De router besluit dat dit verwijst naar de Post controller, de tonen methode en de ID van het bericht dat moet worden weergegeven is 42, zo noemt het de tonen methode met deze parameter. De tonen methode is niet verantwoordelijk voor het gebruik van het model om de gegevens op te halen en het gebruik van de weergave om de uitvoer te creëren. Dus ons uitgebreide [Rails] -blok is nu:
Het model is zowel het eenvoudigst te begrijpen als het moeilijkst te implementeren. Het model is verantwoordelijk voor interactie met de database. De eenvoudigste manier om het uit te leggen is dat het model een eenvoudige set methodeaanroepen is die gewone Ruby-objecten retourneren die alle interacties (lezen en schrijven) uit de database afhandelen. Dus volgens het blogvoorbeeld ziet de API die de controller gebruikt om gegevens op te halen met het model er ongeveer zo uit Post.find (params [: id]). De params is wat de router heeft geparseerd van de URL, Post is het model. Dit maakt SQL-zoekopdrachten of doet wat nodig is om de blogpost op te halen. Modellen bevinden zich in app / modellen.
Het is belangrijk op te merken dat niet alle acties een model hoeven te gebruiken. Interactie met het model is alleen vereist wanneer gegevens uit de database moeten worden geladen of in de database moeten worden opgeslagen. Daarom plaatsen we er een vraagteken achter in ons kleine stroomschema.
Eindelijk is het tijd om wat HTML te genereren. HTML wordt niet afgehandeld door de controller zelf en ook niet door het model. Het punt van het gebruik van een MVC-raamwerk is om alles in compartimenten op te delen. Databasebewerkingen blijven in de modus, HTML-generatie blijft in de weergave en de controller (door de router genoemd) roept ze allebei aan.
HTML wordt normaal gesproken gegenereerd met embedded Ruby. Als je bekend bent met PHP, dat wil zeggen een HTML-bestand met daarin ingesloten PHP-code, dan zal embedded Ruby heel bekend zijn. Deze weergaven bevinden zich in app / weergaven, en een controller zal een van hen aanroepen om de uitvoer te genereren en terug te sturen naar de webserver. Alle gegevens die door de controller met het model worden opgehaald, worden over het algemeen opgeslagen in een instantievariabele die dankzij wat Ruby-magie vanuit de weergave beschikbaar zullen zijn als instantievariabelen. Ook hoeft embedded Ruby geen HTML te genereren, het kan elk type tekst genereren. Dit zie je bij het genereren van XML voor RSS, JSON, etc.
Deze uitvoer wordt teruggestuurd naar de webserver, die deze terugstuurt naar de webbrowser, die het proces voltooit.