Når du skriver egne programmer fra begynnelse til slutt, er det lett å se flytkontroll. Programmet starter her, det er en sløyfe der, metodeanrop er her, det hele er synlig. Men i en Rails-applikasjon er ikke ting så enkelt. Med et rammeverk av noe slag, gir du fra deg kontroll over slike ting som "flyt" til fordel for en raskere eller enklere måte å gjøre kompliserte oppgaver på. Når det gjelder Ruby on Rails, blir flytkontrollen alt håndtert bak kulissene, og alt du sitter igjen med er (mer eller mindre) en samling modeller, visninger og kontrollere.
Kjernen i alle webapplikasjoner er HTTP. HTTP er nettverksprotokollen nettleseren din bruker for å snakke med en webserver. Det er her begreper som "forespørsel", "FÅ" og "POST" kommer fra, de er det grunnleggende vokabularet for denne protokollen. Men siden Rails er en abstraksjon av dette, vil vi ikke bruke mye tid på å snakke om det.
Når du åpner en webside, klikker du på en lenke eller sender et skjema i en nettleser, nettleseren kobler seg til en webserver via TCP / IP. Nettleseren sender så serveren en "forespørsel", tenk på den som en mail-in-skjema som nettleseren fyller ut og ber om informasjon på en bestemt side. Serveren til slutt sender nettleseren et "svar." Ruby on Rails er ikke webserveren, webserveren kan være alt fra Webrick (det som vanligvis skjer når du starter en Rails-server fra de
kommandolinje) til Apache HTTPD (webserveren som driver det meste av nettet). Webserveren er bare en tilrettelegger, den tar forespørselen og overleverer den til Rails-applikasjonen din, som genererer svaret og passerer, er tilbake til serveren, som igjen sender det tilbake til klient. Så flyten så langt er:Noe av det første en Rails-applikasjon gjør med en forespørsel, er å sende den gjennom ruteren. Hver forespørsel har en URL, det er dette som vises i adressefeltet til en nettleser. Ruteren er det som avgjør hva som skal gjøres med den nettadressen, hvis URL-en gir mening og om URL-en inneholder parametere. Ruteren er konfigurert i config / routes.rb.
Først må du vite at det endelige målet med ruteren er å matche en URL med en kontroller og handling (mer om disse senere). Og siden de fleste Rails-applikasjoner er RESTful, og ting i RESTful-applikasjoner er representert ved bruk av ressurser, vil du se linjer som ressurser: innlegg i typiske Rails-applikasjoner. Dette samsvarer med nettadresser som /posts/7/edit med Posts-kontrolleren, redigere handling på Posten med ID 7. Ruteren bestemmer bare hvor forespørsler går. Så [Rails] -blokken vår kan utvides litt.
Nå som ruteren har bestemt seg for hvilken kontroller den skal sende forespørselen til, og til hvilken handling på den kontrolleren, sender den den videre. En kontroller er en gruppe relaterte handlinger alle sammen samlet i en klasse. I en blogg er for eksempel all koden for å se, opprette, oppdatere og slette blogginnlegg samlet i en kontroller som heter "Innlegg." Handlingene er bare normale fremgangsmåter av denne klassen. Kontrollører er lokalisert i app / kontrollører.
Så la oss si at nettleseren sendte en forespørsel om /posts/42. Ruteren bestemmer at dette refererer til Post kontrolleren, forestilling og ID-en for innlegget som skal vises er 42, så det kaller forestilling metoden med denne parameteren. De forestilling metoden er ikke ansvarlig for å bruke modellen til å hente dataene og bruke visningen til å lage utdataene. Så vår utvidede [Rails] -blokk er nå:
Modellen er både den enkleste å forstå og vanskeligst å implementere. Modellen er ansvarlig for å samhandle med databasen. Den enkleste måten å forklare den på er modellen er et enkelt sett metodeanrop som returnerer vanlige Ruby-objekter som håndterer alle interaksjoner (leser og skriver) fra databasen. Så etter bloggeksemplet, vil API-en som kontrolleren vil bruke for å hente data ved å bruke modellen se ut som Post.find (params [: id]). De params er det ruteren analysert fra URL, Post er modellen. Dette stiller SQL-spørsmål, eller gjør det som trengs for å hente blogginnlegget. Modeller er lokalisert i app / modeller.
Det er viktig å merke seg at ikke alle handlinger trenger å bruke en modell. Samhandling med modellen er bare nødvendig når data må lastes fra databasen eller lagres i databasen. Som sådan legger vi et spørsmålstegn etter det i det lille flytskjemaet vårt.
Endelig er det på tide å begynne å generere HTML. HTML håndteres ikke av kontrolleren selv, og den håndteres heller ikke av modellen. Poenget med å bruke et MVC-rammeverk er å seksjonere alt. Databaseoperasjoner holder seg i modus, HTML-generering forblir i visningen, og kontrolleren (kalt av ruteren) kaller dem begge.
HTML genereres normalt ved hjelp av innebygd Ruby. Hvis du er kjent med PHP, det vil si en HTML-fil med PHP-kode innebygd i den, vil innebygd Ruby være veldig kjent. Disse visningene ligger i app / visninger, og en kontroller vil ringe en av dem for å generere output og sende den tilbake til webserveren. Alle data hentet av kontrolleren som bruker modellen, vil vanligvis lagres i et forekomstvariabel som, takket være noen Ruby magi, vil være tilgjengelige som forekomstvariabler fra utsikten. Innebygd Ruby trenger heller ikke å generere HTML, den kan generere alle typer tekst. Dette ser du når du genererer XML for RSS, JSON, etc.
Denne utgangen blir sendt tilbake til webserveren, som sender den tilbake til nettleseren, som fullfører prosessen.