La oss innse det: vi har alle gode ideer til en webapplikasjon. Enten du skriver dem ned på papir eller husker dem ved hjelp av ditt eget minne, kommer det et poeng når du vil teste hvorvidt ideen din er virkelig levedyktig.

I denne opplæringen bruker vi en mikroramme, et templerende språk og en ORM for raskt å utvikle en applikasjonsprototype.

Trinn 1: Introduksjon og oppsett

Vi har alle hatt den følelsen. Du vet, den der du vet at du har en god webapplikasjonsidee, bare du har ikke tid til å piske opp en rask prototype og teste ideen vil virkelig fungere. Ved hjelp av en mikroramme, et templerende språk og en ORM, kan du få den oppe i løpet av få minutter.

For denne opplæringen bruker vi den utmerkede mikrorammen Slim, det templerende språket Twig og den lettvektige flytende ORM Paris og Idiorm. Vår prøveapplikasjon vil bli en blogg. Du har sikkert bygget en blogg før, men vi er her for å lære om mikrorammer, og en blogg passer regningen pent!

Det første du vil gjøre er å ta tak i disse pakkene fra deres respektive nettsteder:

• Slim 1.5.02 (Stabil Release)
• Smarte ekstrautstyr
• Twig 1.1
• Paris og Idiorm

Nå som du har alle pakkene lastet ned til datamaskinen din, er det på tide å konfigurere katalogstrukturen. Vi legger filene inn i rotasjonsmappen vår, så prosjektmappen din skal se slik ut:

"Ikke glem å inkludere .htaccess-filen som følger med Slim."

Nå som vi har fått prosjektet strukturert, fortsett og slett innholdet i Slim index.php fil - vi skriver vår egen litt senere. Du kan også skrape alt annet enn TwigView.php klassefil i Slim extras-pakken.

Trinn 2: Bootstrapping

Våre index.php filen vil fungere som en bootstrap, som vil få Slim, Twig og Paris og Idiorm alle jobber sammen pent. Slank vil omdirigere alle forespørsler til vår søknad her, sjekke eventuelle matchende rutemønstre og deretter sende riktig svar. Denne filen vil til slutt inneholde hele programoppsettet og logikken.

Det første vi må gjøre er å inkludere alle bibliotekene som gjør at magien skjer. Legg til følgende i index.php bootstrap-fil:

  
Hvis alt går bra, bør en forespørsel til søknaden din gjøre absolutt ingenting, noe som er bra!
 
La oss få Twig oppe og løpe. Ved hjelp av Slim-ekstrapakken kan vi la Slim opprette et Twig-miljø for oss. Alt det trenger å vite er katalogen Twig er i, så la oss legge til det i vår bootstrap. Også gå videre og opprett en mall katalog kalt maler i stedet rot mens du er på den. 
 
 // Konfigurasjon TwigView :: $ twigDirectory = __DIR__. '/ Kvist / lib / kvist /';
 
Den neste komponenten i stabelen vår er Paris og Idiorm, vår ORM. Den bruker den innebygde PHP PDO-objektet, slik at du kan bruke Postgres eller SQLite til prototypen din, men for denne opplæringen bruker vi MySQL. Pass på å gi den riktig databaseinformasjon: 
 
 ORM :: configure ( 'MySQL: host = localhost; dbnavn = blog'); ORM :: configure ('brukernavn', 'root'); ORM :: konfigurere ( 'passord', ");
 
Til slutt, la oss få Slim opp og løp. Det er ganske komplisert, jeg tror du er enig: 
 
 // Start Slim. $ app = new Slim (array ('view' => ny TwigView));
 
Et ord med advarsel. Hvis du prøver å kjøre programmet nå, kan du få en kryptisk feil. Ikke panikk! Vi løser det på et øyeblikk ved å legge til noen ruter.
 
 
 Trinn 3: Routing
 
Å legge ruter i Slim er enkelt. Alle smarte må vite er rutebeskrivelsesmetoden (f.eks. GET, POST, PUT etc) og URI for å svare på, og hvordan du svarer. Vi kaster ut de grunnleggende ruter av søknaden vår først og lager gutten til prototypen videre i denne opplæringen.
 
La oss først lage en startrute: 
 
 // Blog Home. $ app-> get ('/', function () bruk ($ app) );
 
Her forteller vi Slim for å svare på alle GET-forespørsler pekt på roten til appen vår. Den endelige lukkeparameteren vil etter hvert inneholde logikken for å generere sideutgangen.
 
La oss legge til en annen rute for visning av en individuell bloggartikkel: 
 
 // Blog View. $ app-> get ('/ view / (id)', funksjon ($ id) bruk ($ app) );
 
Legg merke til forskjellen her? I vår URI-parameter har vi lagt til en slug (: Id), som forteller Slim å forvente en verdi på slutten av URI. 
 
Hvis du noen gang har brukt noen andre PHP-rammer, er du sikkert kjent med dette konseptet. Hvis du ikke er, vil vårt eksempel stemme overens / Se / 1, / Se / 2 etc. 
 
Vi har også passert denne parameteren til vår lukkefunksjon, så vi kan bruke den i vår logikklogikk også. Legg merke til hvordan vi også har passert i applikasjonsvariabelen i lukkingsområdet, med bruk uttalelse? Dette tillater oss å få tilgang til internene av Slim, som vi skal bruke til å hente forespørseldata og gi svar.
 
Våre administrasjonsruter må bruke forskjellige forespørselsmetoder, så la oss legge dem til: 
 
 // Admin Hjem. $ app-> get ('/ admin', funksjon () bruk ($ app) ); // Admin Legg til. $ app-> get ('/ admin / add', funksjon () bruk ($ app) ); // Admin Add - POST. $ app-> post ('/ admin / add', funksjon () bruk ($ app) ); // Admin Edit. $ app-> get ('/ admin / edit / (id)', funksjon ($ id) bruk ($ app) ); // Admin Edit - POST. $ app-> post ('/ admin / edit / (: id)', funksjon ($ id) bruk ($ app) ); // Admin Slett. $ app-> get ('/ admin / delete / (: id)', funksjon ($ id) bruk ($ app) );
 
Du vil legge merke til at vi har noen POST-ruter her inne. Senere bruker vi disse til å behandle skjemaer i admin senteret vårt.
 
Til slutt, vi vil bedre fortelle Slim å kjøre vår søknad.
 
 $ App-> run ();
 
 
 Trinn 4: Modeller
 
Paris og Idiorm gjør byggemodeller for å representere dataene dine enkelt som det gjør det meste av det grunne arbeidet, noe som er bra for rask prototyping. Vi lagrer våre modeller i en katalog som heter modeller, så gå videre og lag den katalogen. Inne i den, lag den grunnleggende Artikkel modell i en fil som heter Article.php:
 
  
Ganske enkelt, va? Paris og Idiorm vil trekke ut all den informasjonen den trenger fra modellens klassenavn og databasetabellen. Mens vi er i det, bør vi sannsynligvis opprette databasen og legge til noen eksempler på data: 
 
 CREATE DATABASE 'blogg' DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci; BRUK "blogg"; Opprett tabell hvis ikke EXISTS 'artikkel' ('id' int (10) usignert IKKE NULL AUTO_INCREMENT, 'tidsstempel' datetime IKKE NULL, 'tittel' varchar (128) IKKE NULL, 'sammendrag' varchar (128) IKKE NULL, 'innhold 'tekst IKKE NULL,' forfatter 'varchar (128) IKKE NULL, PRIMARY KEY (' id ')) ENGINE = MyISAM DEFAULT CHARSET = utf8; INSERT TIL 'artikkel' ('id', 'tidsstempel', 'tittel', 'sammendrag', 'innhold', 'forfatter') VÆRDIER (1, '2011-07-28 02:03:14', 'Hello World ! ',' Lorem ipsum dolor sit amet, consectetur adipisising elit, sed do eiusmod tempor incididunt ut labor et dolore magna aliqua. Ut ',' Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed eiusmod tempor incididunt ut labore et dolore magna Aliqua. Utmerket, men det er ikke noe problem, men du trenger ikke noe annet enn det du har å gjøre. Du er ikke sikker på at du er i stand til å fullføre deg selv, og det er ikke noe annet enn deg selv. (2, '2011-07-28 02:03:14', 'Mer Hello World!', 'Lorem ipsum dolor sit amet Gjør deg raskere og raskere enn du er i verden. Ut ',' Kjør deg selv, vær oppmerksom på hva som skjer ut labore et dolore magna aliqua. Ut som et minimum, det er en utfordring å utøve arbeidet med å utvide ut fra dette. Duis aute irure dolor i reprehenderit i voluptate velit esse cillum dolore eu fugiat nulla pariatur. Uncepteur sint occaecat cupidatat non proident, sunt i culpa de officia deserunt mollit anim id er laborum. ',' Mr Green ');
 
Til slutt, ettersom vi bruker artikkelmodellen på hver side, vil vi inkludere den i oppstartsstedet, like etter hvor vi lastet inn bibliotekene våre: 
 
 // Modeller krever 'modeller / Article.php';
 
 
 Trinn 5: Søknadsfronten
 
Nå som vi har våre programruter alle lagt ut, og våre modeller er konfigurert, er det på tide å begynne å bygge noen sider. Vår frontend på bloggen kommer til å bli ganske enkel, med en liste over alle bloggartikler og en side for å se individuelle artikler.
 
Ved hjelp av det kjedelige flytbare grensesnittet Paris og Idiorm, kan vi raskt lage databasespørsmål, uten å skrive noen rå SQL. La oss trekke ut alle artiklene på hjemmesiden ved hjelp av rutens nedleggelse: 
 
 $ articles = Modell :: fabrikk ('Artikkel') -> order_by_desc ('tidsstempel') -> find_many ();
 
Vi begynner med å kalle modellfabrikkmetoden, som vil dispensere en modellobjekt av typen Artikkel. Herfra har vi et flytende grensesnitt, noe som betyr at vi kan kjede våre kommandoer sammen. Her får vi alle artiklene i databasen, bestilt av tidstempel, i synkende rekkefølge, og deretter forteller Paris at vi vil ha mange artikler returnert. Resultatet av denne spørringen er en rekke artikkelmodellobjekter.
 
For å få resultatene våre til å vises i nettleseren, må vi lage en mal. Slim gir en enkel gjengivelsesmetode for å gjøre dette. Den første parameteren er malen som skal gjengis, og den andre parameteren er en assosiativ rekke data som skal gjøres tilgjengelig for malen, som i vårt tilfelle er våre artikkelobjekter.
 
 returner $ app-> render ('blog_home.html', array ('articles' => $ artikler));
 
Vi skal skrive våre maler ved hjelp av Twig, som gir en ren og enkel tagstruktur med arvsfunksjoner som vi kan bruke til å enkelt lage en nettside uten å bruke PHP. Dette er flott for prototyping, da det betyr å fokusere på å forme sidens utgang, i stedet for å vase gjennom blandet PHP og HTML spaghetti kode.
 
Vi trenger en grunnlayoutfil - en grunnleggende HTML-fil i mappen Maler som kalles layout.html Vil gjøre.
 
        % blokkinnhold% % endblock%  
 
Legg merke til Twig-blokkene? Blokker er kalt regioner som du kan fylle ut med innhold. Vi fyller disse blokkene i våre individuelle sidemaler.
 
Her er et raskt krasj kurs på Twig for å komme deg i gang. 
 
Eventuelle variabler eller uttrykk innenfor  blir automatisk rømt og ekko, mens %% koder gir deg mulighet til å utføre eksekutive setninger som for eksempel betingelse eller for looper.
 
La oss gå selv om du oppretter bloggens startside mal for steg. Ikke glem å opprette en ny mal som heter blog_home.html i mappen Maler.
 
Det første vi vil ha vår mal, er å utvide vårt layout. De strekker tag kan Twig vite at vår mal vil bli arvet fra layout.html fil: 
 
 % utvider 'layout.html'%
 
Nå kan vi bruke samme blokksyntaks som vi brukte tidligere for å fylle ut vårt layout. La oss sette sidetittelen: 
 
 % block page_title% Min blogg % endblock%
 
Twig vil fylle ut side tittel region i layoutet, med det vi definerte i vår mal. For å illustrere kraften til Twig ytterligere, la oss lage innholdsblokken, og bruk noen flere Twig-funksjoner: 
 
 % blokk innhold% % for artikkel i artikler% % else% 
Det er for tiden ingen artikler.
 % endif% % endblock%
 
Husk at vi passerte våre hentede artikler array til vår mal tidligere? Dette er nå tilgjengelig i malen med navnet artikler. Ved å bruke Twigs logikk koder, sløyfe vi gjennom artikler variabel for å sjekke om den eksisterer, og hvis ikke, legger vi ut en høflig advarselsmelding. Vi konsoliderer en til loop og ellers betinget av et sett med koder for enkelt å håndtere et tomt utvalg.
 
La oss vise en liste over bloggartikler på hjemmesiden for å bli kjent med Twigs looping og variable utgangssyntax: 
 
 % blokk innhold% % for artikkel i artikler% 
article.title av article.author
 
article.summary
 % else% 
Det er for tiden ingen artikler.
 % endfor% % endblock%
 
Syntaxen for loop er omvendt av PHP's foreach-setning - vi bruker bare søkeordet i, i stedet for som. Dette løper gjennom vårt utvalg av artikkel objekter, som gjør hver tilgjengelig som en variabel som kalles artikkel innenfor løkken.
 
Inne i løkken bruker vi  koder, som vil ekko ut en rømt verdi. Ja, Twig rømmer automatisk utgangen din, så ikke mer skrive htmlentities ()! Vi får også tilgang til tittelattributtet til vårt artikler ved hjelp av en prikk (.) notasjon, i stedet for den vanlige PHP-pilen (->). Hvis du har skrevet Javascript eller Python, bør du være kjent med noe av denne syntaksen.
  
Så nå som vi har vår grunnleggende hjemmeside lagt ut, la oss få sprekke på den detaljvisningen.
 
 // Blog View. $ app-> get ('/ view / (id)', funksjon ($ id) bruk ($ app) $ article = Modell :: fabrikk ('Artikkel') -> find_one ($ id); $ article instanceof Article) $ app-> notFound (); returner $ app-> render ('blog_detail.html', array ('article' => $ artikkel)););
 
Ved å bruke Paris kan vi raskt ta en artikkel med sin ID ved hjelp av Finn én() metode. Hvis nei Artikkel objekt-forekomst returneres, forteller vi det slanke programmet at siden ikke ble funnet, noe som automatisk vil utløse en 404-feil.
 
Hvis artikkelen er funnet, sender vi den til vår detaljmal, som ser ut som følger:
 
 % utvider 'layout.html'% % block page_title% article.title % endblock% % blokkinnhold% 
article.title
 
Publisert: article.timestamp | date ('jS F Y') av article.author
 
article.content
 
Tilbake til hjemmesiden
 % endblock%
 
Ved å bruke Twigs innebygde filtre, kan vi få tilgang til noen grunnleggende PHP-funksjoner, for eksempel Dato() i våre maler. Klassen attributtet article.timestamp blir automatisk gitt til vårt datafilter som den første parameteren, og vår datoformatstreng blir den andre parameteren.
  
Vi har nå en frontendearbeid, om enn en enkel, men det var ikke lengre å få det oppe og løp. Paris gjør det veldig enkelt å fokusere på å trekke dataene dine ut av databasen, og som vi ser når du lager vårt administrasjonsenter, gjør det enkelt å sette inn og oppdatere poster også.
 
 
 Trinn 6: Søknad på nytt
 
La oss jobbe på et administrasjonsenter for bloggen vår, som vi skal strukturere under URI / admin. Da vi allerede har alle rutene oppsett, la oss skrive logikken for hovedadministratorsenter-siden. Det vil være identisk med vår viktigste bloggoppføringsside, så koden under skal gi full mening: 
 
 // Admin Hjem. $ app-> get ('/ admin', funksjon () bruk ($ app) $ articles = Modell :: fabrikk ('Artikkel') -> order_by_desc ('tidsstempel') -> find_many (); return $ app- > gjengivelse ('admin_home.html', array ('articles' => $ articles)););
 
Vi bruker et enkelt tabelloppsett som har tiltakslinker for å legge til, redigere og slette bloggartikler.
 
Du er allerede kjent med hvordan blokkeringssystemet i Twig fungerer, så la oss bare fokusere på innholdsblokken vår: 
 
 % blokkinnhold% 
Min bloggadministrasjon
 
Legg til artikkel
 % hvis artikler%  % for artikkel i artikler%  % endfor% 
 
 
 
Tittel
 
Dato
 
Forfatter
 
handlinger
 
 
 
 
article.title
 
article.author
 
article.timestamp | date ('jS F Y')
 
Redigere
 
Slett
 
 
 % else% 
Det er for tiden ingen artikler.
 % endif% % endblock%
 
I denne mal bruker vi % if% % else% % endif% logikk. Vi ønsker ikke å vise vårt bordoppslag hvis det ikke finnes noen artikler, så vi ser etter eksistensen før vi bestemmer hva vi skal vise. Vi bruker også dato filter  Metode igjen, som jeg tror du er enig i, er ganske rent og leselig.
  
Hovedadministrasjonssenteret
 
La oss flytte på det virkelige kjøttet i admin senteret vårt: manipulere innhold. Det vi trenger er et skjema som inneholder alle feltene vi må legge til og redigere artikkelen vår. Heldigvis støtter Twig gjenbrukbare deler, så la oss lage et skjema delvis kalt article_form.html:
 
 
 
action_name artikkel
 
 Tittel: 
  
 
 Forfatter: 
  
 
 Sammendrag: 
 article.summary | default ('') 
 
 Innhold: 
 article.content | default ('') 
 
  
 
 
En del er bare en gjenbrukbar mal, den kan fortsatt inneholde standard Twig-logikk. I vår skjema mal bruker vi misligholde filter, som sender ut en standardverdi hvis variabelen den filtrerer er tom eller ikke-eksisterende. Når det gjelder skjemafeltene, sender vi ut en tom streng hvis ingen av artikkelattributtene er til stede. Vi forventer også to variabler for å få skjemaet delvis oppe og i gang. Den første ringte handlings beskriver bare skjemahandlingen for brukerne (f.eks. Legg til eller Rediger) og den andre action_url brukes som form handling.
 
Du har uten tvil lagt merke til hvordan logikken for denne siden er delt inn i to ruter, en for GET og en for POST, noe som betyr at vi må skrive en funksjon for å håndtere hver metode. Vår GET-rute trenger bare å gjengi siden - ingenting for vanskelig. Vi vil bare fortelle Twig om å lage en ny mal: 
 
 // Admin Legg til. $ app-> get ('/ admin / edit / (id)', funksjon ($ id) return $ app-> render ('admin_input.html', array ('action_name' => 'Add', 'action_url '=>' / admin / add ')););
 
Vi overfører de to variablene som forventes av vårt skjema delvis til malen. Snakk om hvilke, la meg forklare hvordan du bruker partiet i vår admin_input.html mal: 
 
 % inkluderer 'article_form.html'%
 
Jeg er sikker på at du antar at det ville være så enkelt, og det er det egentlig. Vi trenger bare å inkludere partiet i en av våre Twig-blokkeregioner, og så vil det vises. Den vil også ha tilgang til alle variabler innenfor omfanget av hovedmalen (dvs. de to variablene vi passerte inn). Twig har noen flotte variabel rekkevidde kontroller og sandboxing sikkerhetsfunksjoner, men de er best lagret for en annen dag.
 
Vår siste innskriftsmal er ganske enkel (se nedenfor) og vil fungere godt når vi bygger våre redigeringsregler også. Jeg antar at du lurer på hvorfor vi plaget med en del i den første palisen, hvis både våre tilleggs- og redigeringsformer vil benytte samme mal. Årsaken er at det gjør det mulig å gjenbruke skjemaet andre steder under prototyping, en ekte bris å gjøre, hvis det blir nødvendig.
 
 % utvider 'layout.html'% % blokk side_title% action_name Artikkel % endblock% % blokk innhold% % include 'article_form.html'% % endblock%
  
Legg til en artikkel skjema
 
La oss jobbe med den POST-ruten. Det vi trenger å gjøre er å ta tak i de opplastede dataene, og lagre den inne i et artikkelobjekt. Vi bryr oss ikke om feilkontroll i vårt eksempel siden vi bare prototyperer ideen vår. Vi får Paris til å dispensere, eller opprette, en ny artikkel gjenstand: 
 
 $ article = Modell :: fabrikk ('Artikkel') -> create ();
 
Vi kan nå fortsette med å fylle artikkelen fra de utgitte dataene. Vi tar tak i POST-dataene fra vårt Slim-applikasjonsobjekt, som gir en praktisk hjelpemetode via forespørselsobjektet: 
 
 $ article-> title = $ app-> request () -> post ('title'); $ article-> author = $ app-> request () -> post ('author'); $ article-> summary = $ app-> request () -> post ('sammendrag'); $ article-> content = $ app-> request () -> post ('innhold'); $ article-> timestamp = date ('Y-m-d H: i: s');
 
Paris tar seg av å unnslippe alt vårt innspill når du sparer, noe som er praktisk, bør du noen gang bestemme deg for å plassere prototypen din for andre å få tilgang til. Alt vi trenger å gjøre nå, er å fortelle Paris å lagre posten.
 
 $ Artikkel-> Lagre ();
 
Til slutt forteller vi vårt Slim-program for å ta oss tilbake til hovedadministrasjonens dashboardside ved hjelp av omdirigere hjelpemetode: 
 
 $ App-> omdirigere ( '/ admin');
 
På vår redigeringsrute GET-metode, som bare er en sammenblanding av tingene vi har lært, fra å bygge vår bloggdetaljerside og vår admin-tilleggsside. Først må vi laste opp artikkelen vi redigerer, ved å hente platen med Paris: 
 
 $ article = Modell :: fabrikk ('Artikkel') -> find_one ($ id); hvis (! $ artikkel instanceof Article) $ app-> notFound (); 
 
Paris sender en artikkelobjekt-forekomst som matcher artikkel-post-ID mottatt i lukkingen vår, eller falsk hvis ingen finnes. Vi sjekker da for å se om vi fikk en forekomst tilbake, om ikke vi forteller Slim for å kaste en 404-feil.
 
Vi forteller nå Slim for å gjengi inngangsmalen, som i vår leggerute, men passerer i det lastede artikkelen objektet og den riktige handlingsadressen: 
 
 returner $ app-> render ('admin_input.html', array ('action_name' => 'Rediger', 'action_url' => '/ admin / rediger /'. $ id, 'article' => $ artikkel));
 
Vår POST redigeringsrute fungerer nesten identisk med Legg til rute, med unntak av at vi må sjekke om artikkelen kan lastes inn før vi går videre og oppdaterer dens attributter: 
 
 $ article = Modell :: fabrikk ('Artikkel') -> find_one ($ id); hvis (! $ artikkel instanceof Article) $ app-> notFound ();  $ artikkel-> title = $ app-> request () -> post ('title'); $ article-> author = $ app-> request () -> post ('author'); $ article-> summary = $ app-> request () -> post ('sammendrag'); $ article-> content = $ app-> request () -> post ('innhold'); $ article-> timestamp = date ('Y-m-d H: i: s'); $ Artikkel-> Lagre (); $ App-> omdirigere ( '/ admin');
 
Vi avslutter vårt administrasjonsenter ved å bygge slettingsruten. Vi gjør dette ved først å hente posten, som ligner på hvordan vi gjorde på vår bloggdetaljerside tidligere: 
 
 $ article = Modell :: fabrikk ('Artikkel') -> find_one ($ id);
 
Hvis Paris lastet inn en artikkel, må vi slette den, og deretter sende brukeren tilbake til hovedadministrasjonssiden. Paris gjør sletting av en plate så enkel som mulig: 
 
 hvis ($ article instanceof Article) $ article-> delete ();  $ app-> omdirigering ('/ admin');
 
Og med det er vår grunnleggende prototype admin senter gjort.
 
 
 Trinn 7: Bruk Middleware
 
Vårt administrasjonsenter er nå fullført. Det er ganske grunnleggende siden det bare er en prototype, men vi vil fortsatt ha en form for autorisasjon på den for å beskytte den mot nysgjerrige øyne. Slim gjør at vi kan sette inn mellomvare i våre ruter. Hva dette betyr er at vi kan skape funksjoner som blir kalt før rutenes responsavslutning gjør det.
 
Vi kan bruke HTTP Basic Auth for å beskytte vårt administrasjonsenter. Åpenbart vil vi bruke noe litt sikrere på et nettsted, men for vår prototype er dette greit. På toppen av vår index.php la oss lage to konstanter som inneholder vårt brukernavn og passord: 
 
 // Auth Detaljer. define ('USERNAME', 'admin'); define ('passord', 'passord');
 
Etter at vi opprettet vår Slim Application-forekomst, lager vi en nedleggelse, som vi vil binde til en variabel for å beholde vår autorisasjon mellomvarekontroll: 
 
 // Auth Sjekk. $ authCheck = funksjon () bruk ($ app) ;
 
Hvis du aldri har brukt HTTP Basic Auth i PHP før, er det veldig enkelt. Vi kan bruke $ _SERVER array for å sjekke hvilke legitimasjonsbeskrivelser som ble sendt fra brukerens nettleser, og sammenligne dem med våre konstanter. Vi gjør dette i vår nyopprettede nedleggelse. Det første vi må gjøre i vår auth-sjekkefunksjon, er å finne ut om noen auth-legitimasjon er sendt, og hvis de var, sjekk for å se om de samsvarer med våre konstanter: 
 
 $ authRequest = isset ($ _ SERVER ['PHP_AUTH_USER'], $ _SERVER ['PHP_AUTH_PW']); $ authUser = $ authRequest && $ _SERVER ['PHP_AUTH_USER'] === USERNAME; $ authPass = $ authRequest && $ _SERVER ['PHP_AUTH_PW'] === PASSWORD;
 
Alt vi gjør her, er å kontrollere om authverdiene eksisterer og samsvarer, og lagrer resultatene i enkelte variabler. Forutsatt at noen av disse variablene er falske, vet vi at vi må be brukeren om å autorisere seg selv:
 
 $ app-> respons () -> header ('WWW-Authenticate $ app-> response () -> header ('HTTP / 1.1 401 Uautorisert', ''); $ App-> respons () -> kroppen ('
Vennligst skriv inn gyldig administrasjonsinformasjon
'); $ App-> respons () -> send (); exit; 
 
Vi sjekker om våre autentiske opplysninger er i orden. Hvis de ikke er det, sender vi et svar tilbake med de aktuelle overskriftene og varselsmeldingen. Som du så tidligere, kunne vi få tilgang til objektet Slim Framework Request for å få tilgang til POST-dataene våre. Vi kan også få tilgang til det interne responsobjektet, noe som gjør det enkelt for oss å skyve inn i våre overskrifter og overskrive Slim Respons Object Body med en enkel HTML-advarsel, før vi endelig tvinger skriptet til å gå ut.
 
I Slim kan du legge til flere callables til en rute, og de blir henrettet i den rekkefølgen de er angitt. Hva dette betyr er at vi enkelt kan forhindre tilgang til alle våre ruter ved å legge til kontrollen av autokontroll før svaret lukkes: 
 
 // Admin Hjem. $ app-> get ('/ admin', $ authCheck, funksjon () bruk ($ app) //?); // Admin Legg til. $ app-> get ('/ admin / add', $ authCheck, funksjon () bruk ($ app) //?); // Admin Add - POST. $ app-> post ('/ admin / add', $ authCheck, funksjon () bruk ($ app) //?); // Admin Edit. $ app-> get ('/ admin / edit / (id)', $ authCheck, funksjon ($ id) bruk ($ app) //?); // Admin Edit - POST. $ app-> post ('/ admin / edit / (id)', $ authCheck, funksjon ($ id) bruk ($ app) //?); // Admin Slett. $ app-> get ('/ admin / delete / (: id)', $ authCheck, funksjon ($ id) bruk ($ app) //?);
 
Og der har du det, vårt administrasjonsenter er nå beskyttet. Alle som prøver å få tilgang til den, vil se en advarsel og bli bedt om deres legitimasjon.
  
 
 Trinn 8: Sammendrag
 
Forhåpentligvis har denne opplæringen vist deg hvor raskt og enkelt det er å få en prototype oppe i gang med en mikroramme, et ORM og malingsspråk, samtidig som du opprettholder god separasjon av bekymringer og lesbar kode.
 
Et kraftig templerende språk kan forhindre at visningene dine kommer til å ende opp som en blanding av ulestelig PHP- og HTML-spagetti-kode, og hvordan en flytende ORM kan gjøre kjedelige CRUD-handlinger raskt og smertefritt.
 
Dette er bare noen av de mange kule tingene du kan gjøre med Slim, Twig og Paris. Hvis du graver videre, kan du legge til relasjoner til modellene dine med Paris, legge til makroutdrag i Twig for å akselerere utviklingen av malene og bruke navngitt ruting med Slim for å gjøre sammenkobling av nettstedets innhold og endring av webadresser trivielt.
 
Glad prototyping og takk så mye for lesing!



		
			
	   
	




Kode