Når du skriver dine egne programmer fra begyndelse til slutning, er det let at se flowstyring. Programmet starter her, der er en løkke der, metodeopkald er her, det hele er synligt. Men i en Rails-applikation er tingene ikke så enkle. Med en ramme af enhver art, giver du afkald på kontrol med ting som "flow" til fordel for en hurtigere eller enklere måde at udføre komplekse opgaver på. Når det gælder Ruby on Rails, håndteres flowkontrollen bag kulisserne, og alt hvad du har tilbage med er (mere eller mindre) en samling modeller, visninger og controllere.
Kernen i enhver webapplikation er HTTP. HTTP er den netværksprotokol, din webbrowser bruger til at tale med en webserver. Det er her udtryk som "anmodning", "GET" og "POST" kommer fra, de er det grundlæggende ordforråd i denne protokol. Da Rails er en abstraktion af dette, bruger vi ikke meget tid på at tale om det.
Når du åbner en webside, skal du klikke på et link eller indsende en formular i en webbrowser, browseren opretter forbindelse til en webserver via TCP / IP. Browseren sender derefter serveren en "anmodning", tænk på den som en mail-in-form, som browseren udfylder og beder om oplysninger på en bestemt side. Serveren sender i sidste ende webbrowseren et "svar". Ruby on Rails er dog ikke webserveren, webserveren kan være alt fra Webrick (hvad der normalt sker, når du starter en Rails-server fra det
kommandolinje) til Apache HTTPD (webserveren, der driver det meste af internettet). Webserveren er bare en facilitator, den tager anmodningen og overleverer den til din Rails-applikation, som genererer svaret og videregiver er tilbage til serveren, som igen sender det tilbage til klient. Så strømmen indtil videre er:En af de første ting, en Rails-applikation gør med en anmodning, er at sende den gennem routeren. Hver anmodning har en URL, det er det, der vises i adresselinjen i en webbrowser. Routeren er det, der bestemmer, hvad der skal gøres med den URL, hvis URL'en giver mening, og hvis URL'en indeholder parametre. Routeren er konfigureret i config / routes.rb.
Ved først, at det ultimative mål med routeren er at matche en URL med en controller og handling (mere om disse senere). Og da de fleste Rails-applikationer er RESTful, og ting i RESTful-applikationer er repræsenteret ved hjælp af ressourcer, ser du linjer som ressourcer: indlæg i typiske Rails-applikationer. Dette matcher URL'er som /posts/7/edit med Posts controller, the redigere handling på posten med ID af 7. Routeren bestemmer bare, hvor anmodninger skal hen. Så vores [Rails] -blok kan udvides en smule.
Nu hvor routeren har besluttet, hvilken controller der skal sendes anmodningen til, og til hvilken handling på den controller, sender den den videre. En controller er en gruppe relaterede handlinger, alle sammen samlet i en klasse. I en blog er f.eks. Al koden til visning, oprettelse, opdatering og sletning af blogindlæg samlet i en controller kaldet "Post". Handlingerne er bare normale metoder af denne klasse. Controllere er placeret i APP / controllere.
Så lad os sige, at webbrowseren sendte en anmodning om /posts/42. Routeren beslutter, at dette refererer til Stolpe controller, at vise metode og ID for det post, der skal vises, er 42, så det kalder at vise metode med denne parameter. Det at vise metoden er ikke ansvarlig for at bruge modellen til at hente dataene og bruge visningen til at oprette output. Så vores udvidede [Rails] -blok er nu:
Modellen er både den enkleste at forstå og vanskeligst at implementere. Modellen er ansvarlig for interaktion med databasen. Den enkleste måde at forklare den på er modellen er et simpelt sæt metodekald, der returnerer almindelige Ruby-objekter, der håndterer alle interaktioner (læser og skriver) fra databasen. Så efter blogeksemplet vil API'en, som controlleren bruger til at hente data ved hjælp af modellen, se ud som Post.find (params [: id]). Det params er, hvad routeren analyserede fra URL, Post er modellen. Dette gør SQL-forespørgsler, eller gør hvad der er nødvendigt for at hente blogindlægget. Modeller findes i APP / modeller.
Det er vigtigt at bemærke, at ikke alle handlinger skal bruge en model. Det er kun nødvendigt at interagere med modellen, når data skal indlæses fra databasen eller gemmes i databasen. Som sådan lægger vi et spørgsmålstegn efter det i vores lille flowchart.
Endelig er det tid til at begynde at generere HTML. HTML håndteres ikke af selve controlleren, og det håndteres heller ikke af modellen. Pointen med at bruge en MVC-ramme er at opdele alt. Databasefunktioner forbliver i tilstanden, HTML-generation forbliver i visningen, og controlleren (kaldet af routeren) kalder dem begge.
HTML genereres normalt ved hjælp af indlejret Ruby. Hvis du er bekendt med PHP, det vil sige en HTML-fil med PHP-kode indlejret i den, vil indlejret Ruby være meget velkendt. Disse synspunkter er placeret i APP / visninger, og en controller kalder en af dem for at generere output og sende den tilbage til webserveren. Alle data, der hentes af controlleren, der bruger modellen, gemmes normalt i en forekomstvariabel som takket være nogle Ruby-magier vil være tilgængelige som forekomstvariabler fra visningen. Indlejret Ruby behøver heller ikke at generere HTML, det kan generere enhver type tekst. Dette ser du, når du genererer XML til RSS, JSON osv.
Denne output sendes tilbage til webserveren, der sender den tilbage til webbrowseren, som afslutter processen.