Låt oss möta det: vi har alla bra idéer för en webbapplikation. Oavsett om du skriver ner dem på papper eller kommer ihåg dem med ditt eget minne, kommer det en punkt när du vill prova huruvida din idé är verkligen livskraftig.

I denna handledning använder vi en mikroram, ett templerande språk och en ORM för att snabbt utveckla en applikationsprototyp.

Steg 1: Introduktion och inställning

Vi har alla haft den känslan. Du vet, den där du vet att du har en bra webbapplikationside, bara du har inte tid att piska upp en snabb prototyp och testa idén kommer verkligen att fungera. Med hjälp av en mikroram, ett templerande språk och en ORM kan du få igång det på några minuter.

För den här handledningen använder vi den utmärkta mikroramen Slim, det templerande språket Twig och den lättvikta flytande ORM Paris och Idiorm. Vårt provansökan blir en blogg. Du har förmodligen byggt en blogg förut, men vi är här för att lära oss om mikroramar, och en blogg passar räkningen snyggt!

Det första du vill göra är att ta tag i dessa paket från sina respektive webbplatser:

• Slim 1.5.02 (Stabil Release)
• Smarta Extra
• Twig 1.1
• Paris och Idiorm

Nu när du har alla paket nedladdade till din dator är det dags att konfigurera din katalogstruktur. Vi lägger in filerna i vår rotationsmapp, så din projektmapp ska se ut så här:

"Glöm inte att inkludera .htaccess-filen som kommer med Slim."

Nu när vi har strukturerat vårt projekt, fortsätt och ta bort innehållet i Slim index.php fil - vi skriver lite senare senare. Du kan också skrapa allt utom TwigView.php klassfil i Slim extras-paketet.

Steg 2: Bootstrapping

Vår index.php filen kommer att fungera som en bootstrap, som kommer att få Slim, Twig och Paris och Idiorm alla samarbeta snyggt. Slim kommer att omdirigera alla förfrågningar till vår ansökan här, kolla efter eventuella matchande ruttmönster och sedan skicka det lämpliga svaret. Den här filen innehåller så småningom hela vår installationsprogram och logik.

Det första vi behöver göra är att inkludera alla bibliotek som gör att magin händer. Lägg till följande i index.php bootstrap-fil:

  
Om allt går bra, bör en ansökan till din ansökan göra absolut ingenting, vilket är bra!
 
Nu får vi Twig upp och springa. Genom att använda Slim Extra-paketet kan vi låta Slim installera en Twig-miljö för oss. Allt som behövs är katalogen Twig är in, så låt oss lägga till det i vår bootstrap. Fortsätt också och skapa en mall katalog som heter mallar i platsrot när du är på den. 
 
 // Konfiguration TwigView :: $ twigDirectory = __DIR__. '/ Kvist / lib / kvist /';
 
Nästa komponent i vår stack är Paris och Idiorm, vår ORM. Det använder det inbyggda PHP PDO-objektet, så du kan använda Postgres eller SQLite för din prototyp, men för den här handledningen använder vi MySQL. Var noga med att ge den rätt databasinformation: 
 
 ORM :: configure (mysql: host = localhost, dbname = blogg '); ORM :: configure ('användarnamn', 'root'); ORM :: configure (lösenord ",");
 
Slutligen, låt oss få Slim upp och springa. Det är ganska komplicerat, jag tror att du håller med om: 
 
 // Start Slim. $ app = new Slim (array ('view' => new TwigView));
 
Ett varningstecken. Om du försöker köra din ansökan nu kan du få ett kryptiskt fel. Var inte panik! Vi löser det på ett ögonblick genom att lägga till några rutter.
 
 
 Steg 3: Routing
 
Lägga till rutter i Slim är enkelt. Alla smarta måste veta är rutebeskrivningsmetoden (t.ex. GET, POST, PUT etc) och URI att svara på och hur man svarar. Vi släpper ut de grundläggande rutorna för vår applikation först och skapar prototypens tarmar vidare i denna handledning.
 
Låt oss först skapa en hemsidaväg: 
 
 // Blogg Hem. $ app-> get ('/', function () använd ($ app) );
 
Här berättar vi Slim för att svara på någon GET-förfrågan som pekas på grunden till vår app. Den slutliga stängningsparametern innehåller så småningom logiken för att generera sidoutgången.
 
Låt oss lägga till en annan rutt för att visa en enskild bloggartikel: 
 
 // Blog View. $ app-> get ('/ view / (id)', funktion ($ id) användning ($ app) );
 
Observera skillnaden här? I vår URI-parameter har vi lagt till en slug (: Id), som berättar Slim att förvänta sig ett värde i slutet av URI. 
 
Om du någonsin har använt någon annan PHP-ram har du förmodligen bekantskap med detta koncept. Om du inte är, skulle vårt exempel matcha / View / 1, / View / 2 etc. 
 
Vi har också passerat den här parametern till vår stängningsfunktion, så vi kan använda den i vår applikationslogik också. Lägg märke till hur vi också har passerat i vår applikationsvariabel i stängningsområdet, med använda sig av påstående? Detta gör det möjligt för oss att komma åt internals av Slim, som vi ska använda för att ta tag i förfrågningsdata och göra svar.
 
Våra administrationsvägar måste använda olika förfrågningsmetoder, så låt oss lägga till dem i: 
 
 // Admin Hem. $ app-> get ('/ admin', funktion () använd ($ app) ); // Admin Add. $ app-> get ('/ admin / add', funktion () använd ($ app) ); // Admin Add - POST. $ app-> post ('/ admin / add', funktion () använd ($ app) ); // Admin Edit. $ app-> get ('/ admin / edit / (id)', funktion ($ id) användning ($ app) ); // Admin Edit - POST. $ app-> post ('/ admin / edit / (id)', funktion ($ id) användning ($ app) ); // Admin Delete. $ app-> get ('/ admin / delete / (id)', funktion ($ id) användning ($ app) );
 
Du märker att vi har några POST-rutter här. Senare använder vi dessa för att bearbeta formulär i vårt admincenter.
 
Slutligen, vi skulle bättre berätta Slim för att köra vår ansökan.
 
 $ App> run ();
 
 
 Steg 4: Modeller
 
Paris och Idiorm gör byggnadsmodeller för att representera dina data enkelt som det gör det mesta av det grunt arbetet, vilket är bra för snabb prototypning. Vi lagrar våra modeller i en katalog som heter modeller, så fortsätt och skapa den katalogen. Inuti den, skapa den grundläggande Artikel modell i en fil som heter Article.php:
 
  
Ganska enkelt, va? Paris och Idiorm kommer att extrahera all information som behövs från modellens klassnamn och databastabellen. Medan vi är på det borde vi noga skapa databasen och lägga till några provdata: 
 
 CREATE DATABASE "blogg" DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci; ANVÄND "blogg"; SKAPA TABELL OM INTE EXISTERAR 'artikel' ('id' int (10) unsigned INTE NULL AUTO_INCREMENT, 'tidsstämpel' datetime INTE NULL, 'titel' varchar (128) INTE NULL, "sammanfattning" varchar (128) INTE NULL, "innehåll 'text NOT NULL,' författare 'varchar (128) INTE NULL, PRIMARY KEY (' id ')) MOTOR = MyISAM DEFAULT CHARSET = utf8; INSERT INTO 'artikel' ('id', 'tidsstämpel', 'titel', 'sammanfattning', 'innehåll', 'författare') VÄRDEN (1, '2011-07-28 02:03:14', 'Hello World ! ',' Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut ',' Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed gör eiusmod tempor incididunt ut labore et dolore magna Aliqua. Utan minsta möjliga vänskap, men det är inte nödvändigt att utöva ett annat arbete än det här. Därför är det viktigt att du är i fullmakt när du är en del av din familj, och du kommer inte att vara säker på att du är säker på det. (2, "2011-07-28 02:03:14", "Mer hej världen!", "Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed gör det ojämnaste tillfället att du kommer att arbeta med en dolore magna aliqua. Ut ',' Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Utan minsta möjliga vänskap, det är inte nödvändigt att utöva arbetskraftsarbeten och utifrån det som följer. Duis aute irure dolor i reprehenderit i voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt i culpa qui officia förlorade mollit anim id s laborum. ',' Mr Green ');
 
Slutligen, eftersom vi använder artikelmodellen på varje sida, tar vi den med i vår bootstrap, strax efter där vi laddade våra bibliotek: 
 
 // Modeller kräver 'modeller / Article.php';
 
 
 Steg 5: Ansökningsfronten
 
Nu när vi har våra applikationsrutter utlagda och våra modeller konfigurerade, är det dags att börja bygga några sidor. Vår bloggfrontändring kommer att bli ganska enkel, med en lista över alla bloggartiklar och en sida för att visa enskilda artiklar.
 
Med hjälp av det kedjbara flytbara gränssnittet Paris och Idiorm, kan vi snabbt konstruera databasfrågor utan att skriva någon rå SQL. Låt oss dra ut alla artiklar på hemsidan med hjälp av rutten stängning: 
 
 $ articles = Modell :: factory ('Article') -> order_by_desc ('timestamp') -> find_many ();
 
Vi börjar med att ringa modellfabrikmetoden, som kommer att avge ett modellobjekt av typen Artikel. Härifrån har vi ett flytande gränssnitt, vilket innebär att vi kan kombinera våra kommandon tillsammans. Här får vi alla artiklar i databasen, beställda av deras tidstämpel, i fallande ordning och sedan berätta för Paris vi vill att många artiklar returneras. Resultatet av denna fråga är en rad artikelmodellobjekt.
 
För att få våra resultat att dyka upp i webbläsaren behöver vi göra en mall. Slim ger en enkel återställningsmetod för att göra detta. Den första parametern är mallen för att göra och den andra parametern är en associativ grupp av data som ska göras tillgänglig för mallen, vilket i vårt fall är våra artikelobjekt.
 
 returnera $ app-> render ('blog_home.html', array ('articles' => $ articles));
 
Vi skriver våra mallar med Twig, vilket ger en ren och enkel taggstruktur med arv funktioner som vi kan använda för att enkelt skapa en webbsida utan att använda någon PHP. Det här är bra för prototypning, eftersom det innebär att man fokuserar på att forma sidutmatningen, istället för att bläddra i blandad PHP- och HTML-spaghettikod.
 
Vi behöver en baslayoutfil - en grundläggande HTML-fil i din mappmall som heter layout.html ska göra.
 
        % block content% % endblock%  
 
Lägg märke till Twig block-taggarna? Block är namngivna regioner som du kan fylla i med innehåll. Vi fyller i dessa block i våra enskilda sidmallar.
 
Här är en snabbkrasch på Twig för att få dig att gå. 
 
Varje variabel eller uttryck inom  rymmer automatiskt och echoes, medan %% taggar tillåter dig att använda exekutiva uttalanden som om annars villkor eller loopar.
 
Låt oss gå men skapa bloggens startsida mall steg för steg. Glöm inte att skapa en ny mall som heter blog_home.html i din mallar mapp.
 
Det första vi vill att vår mall ska göra är att utöka vår layout. De sträcker taggar kan Twig veta att vår mall kommer att ärva från layout.html fil: 
 
 % utökar 'layout.html'%
 
Nu kan vi använda samma blocksyntax som vi tidigare använde för att fylla vår layout. Låt oss ange sidtiteln: 
 
 % block page_title% Min blogg % endblock%
 
Twig kommer att fylla i sidans titel regionen i layouten, med det vi definierade i vår mall. För att illustrera Twigs kraft ytterligare, låt oss skapa innehållsblocket och använda några fler Twig-funktioner: 
 
 % block content% % för artikel i artiklar% % else% 
Det finns för närvarande inga artiklar.
 % endif% % endblock%
 
Kom ihåg att vi passerade våra hämtade artiklar till vår mall tidigare? Detta är nu tillgängligt i mallen med namnet artiklar. Med hjälp av Twigs logik taggar vi genom artiklar variabel för att kontrollera om det existerar och om det inte gör, lägger vi ut ett artigt varningsmeddelande. Vi konsoliderar a för loop och annan villkoras i en uppsättning taggar för att enkelt hantera en tom matris.
 
Låt oss visa en lista med bloggartiklar på hemsidan för att bekanta oss med Twiggs looping och variabel syntax för synkronisering: 
 
 % block content% % för artikel i artiklar% 
article.title av article.author
 
article.summary
 % else% 
Det finns för närvarande inga artiklar.
 % endfor% % endblock%
 
Synkronisera för slinga är omvänd av PHP: s uttalande - vi använder bara sökordet i, istället för som. Detta loopar genom vårt utbud av artikel objekt som gör var och en tillgänglig som en variabel som heter artikel inom slingan.
 
Inuti slingan använder vi  taggar, som kommer att echo ett escape-värde. Ja, Twig undviker automatiskt din produktion, så det går inte längre att skriva htmlentities ()! Vi har även tillgång till vårt artikeltitelattribut med hjälp av en punkt (.) notation, istället för den vanliga PHP-pilen (->). Om du har skrivit Javascript eller Python borde du vara bekant med en del av denna syntax.
  
Så nu när vi har lagt ut vår grundläggande hemsida, låt oss få spricka på den detaljvy.
 
 // Blog View. $ app-> get ('/ view / (id)', funktion ($ id) användning ($ app) $ article = Modell :: fabriks ('Artikel') -> find_one ($ id); $ article instanceof Article) $ app-> notFound (); returnera $ app-> render ('blog_detail.html', array ('article' => $ artikel)););
 
Med Paris kan vi snabbt ta tag i en artikel med sitt ID med hjälp av hitta en() metod. Om inte Artikel Objektförekomst returneras, vi berättar för Slim-programmet att sidan inte hittades, vilket automatiskt kommer att utlösa ett 404-fel.
 
Om artikeln hittas skickar vi den till vår detaljmall, som ser ut som följer:
 
 % sträcker 'layout.html'% % block page_title% article.title % endblock% % block content% 
 artikelrubrik 
 
Publicerad: article.timestamp | date ('jS F Y') av article.author
 
article.content
 
Tillbaka till startsidan
 % endblock%
 
Med hjälp av Twigts inbyggda filter kan vi komma åt några grundläggande PHP-funktioner, till exempel datum() i våra mallar. Klassattributet article.timestamp ges automatiskt till vårt datumfilter som den första parametern, och vår datumformatsträng blir den andra parametern.
  
Vi har nu en frontändararbete, om än en enkel, men det längtade inte på att få det igång. Paris gör det väldigt lätt att fokusera på att dra data ut ur databasen, och som vi ser när vi skapar vårt admincenter gör det enkelt att infoga och uppdatera poster också.
 
 
 Steg 6: Ansökans baksida
 
Låt oss arbeta på ett admincenter för vår blogg, som vi ska strukturera under URI /administration. Med tanke på att vi redan har alla rutininställningar, låt oss skriva logiken för huvudadministratörscentrumsidan. Det kommer att vara identiskt med vår huvudsakliga bloggnotationssida, så koden nedan borde göra fullständig mening: 
 
 // Admin Hem. $ app-> get ('/ admin', funktion () använd ($ app) $ articles = Modell :: factory ('Article') -> order_by_desc ('timestamp') -> find_many > render ('admin_home.html', array ('articles' => $ articles)););
 
Vi använder en enkel tabelllayout som har åtkomstlänkar för att lägga till, redigera och ta bort bloggartiklar.
 
Du är redan bekant med hur blockregionens system i Twig fungerar, så låt oss bara fokusera på vårt innehållsblock: 
 
 % block content% 
Min bloggadministration
 
Lägg till artikel
 % om artiklar%  % för artikel i artiklar%  % endfor% 
 
 
 
Titel
 
Datum
 
Författare
 
Åtgärder
 
 
 
 
 artikelrubrik 
 
article.author
 
article.timestamp | date ('jS F Y')
 
Redigera
 
Radera
 
 
 % else% 
Det finns för närvarande inga artiklar.
 % endif% % endblock%
 
I denna mall använder vi % if% % else% % endif% logik. Vi vill inte visa vår tabelluppsättning om det inte finns några artiklar, så vi kontrollerar förekomsten av det innan vi bestämmer vad vi ska visa. Vi använder också datum filter  Metod igen, som jag tror att du håller med är ganska ren och läsbar.
  
Huvudadministratörscentralen
 
Låt oss flytta på vårt äkta kött i vårt admincenter: manipulera innehållet. Vad vi behöver är en form som innehåller alla de fält vi behöver lägga till och redigera vår artikel. Lyckligtvis stöttar Twig återanvändbara partier, så låt oss skapa en form partiell kallad article_form.html:
 
 
 
action_name artikel
 
 Titel: 
  
 
 Författare: 
  
 
 Sammanfattning: 
 article.summary | default ('') 
 
 Innehåll: 
 article.content | default ('') 
 
  
 
 
En del är helt enkelt en återanvändbar mall, den kan fortfarande innehålla standard Twig-logik. I vår formulärmall använder vi standard filter, som matar ut ett standardvärde om den variabel den filtrerar är tom eller obefintlig. När det gäller våra formulärfält kommer vi att mata ut en tom sträng om ingen av artikelattributen är närvarande. Vi förväntar oss också två variabler för att få vår form delvis upp och köra. Den första ringde åtgärds beskriver bara formuläråtgärden för våra användare (t.ex. Lägg till eller Redigera) och den andra action_url används som form handling.
 
Du har utan tvekan märkt hur logiken för den här sidan är uppdelad i två rutter, en för GET och en för POST, vilket innebär att vi måste skriva en funktion för att hantera varje metod. Vår GET-väg behöver bara återge sidan - inget för knepigt. Vi berätta bara för Twig att göra en ny mall: 
 
 // Admin Add. $ app-> get ('/ admin / edit / (id)', funktion ($ id) return $ app-> render ('admin_input.html', array ('action_name' => 'Lägg till', 'action_url '=>' / admin / add ')););
 
Vi överför de två variablerna som förväntas av vår form delvis i mallen. Tala om vilka, låt mig förklara hur man använder partiet i vårt admin_input.html mall: 
 
 % include 'article_form.html'%
 
Jag är säker på att du antagligen antagit att det skulle vara så enkelt, och det är det verkligen. Vi behöver bara inkludera partiet inuti ett av våra Twig-blockregioner, och då kommer det att visas. Det kommer också att ha tillgång till alla variabler inom ramen för sin huvudmall (dvs de två variablerna vi passerade in). Twig har några stora variabel räckvidd kontroller och sandboxing säkerhetsfunktioner, men de är bäst sparade för en annan dag.
 
Vår sista inmatningsmall är ganska enkel (se nedan) och fungerar bra när vi bygger våra redigeringskontroller också. Jag antar att du undrar varför vi störde med en del i den första palceen, om både våra lägg till och redigera formulär kommer att använda samma mall. Anledningen är att det gör det möjligt att återanvända formuläret någon annanstans under prototyperna.
 
 % sträcker 'layout.html'% % block page_title% action_name Artikel % endblock% % block content% % include 'article_form.html'% % endblock%
  
Lägg till en artikelformulär
 
Låt oss arbeta på den POST-rutten. Vad vi behöver göra är att ta tag i den upplagda data och lagra den i ett artikelobjekt. Vi stör inte med felkontroll i vårt exempel eftersom vi bara prototyper vår idé bara. Vi får Paris att avstå, eller skapa, en ny artikel objekt: 
 
 $ article = Model :: factory ('Article') -> skapa ();
 
Vi kan nu fortsätta med att fylla artikeln från de postade uppgifterna. Vi tar tag i POST-data från vårt smarta applikationsobjekt, vilket ger en praktisk hjälpmetod via dess begäranobjekt: 
 
 $ article-> title = $ app-> request () -> post ('title'); $ article-> author = $ app-> request () -> post ("author"); $ article-> summary = $ app-> request () -> post ('summary'); $ article-> content = $ app-> request () -> post ('content'); $ article-> timestamp = date ('Y-m-d H: i: s');
 
Paris tar hand om att komma undan alla våra inmatningar när du sparar, vilket är praktiskt om du någonsin skulle bestämma att föra din prototyp för att andra ska kunna komma åt. Allt vi behöver göra nu berättar för Paris att spara posten.
 
 $ Artikel-> Spara ();
 
Slutligen berättar vi om vår smarta applikation för att ta oss tillbaka till huvudadministratorpanelen med hjälp av dirigera om hjälparmetod: 
 
 $ App-> omdirigera ( '/ admin');
 
På vår redigeringsväg GET-metod, som helt enkelt är en sammanslagning av de saker som vi har lärt oss från att bygga vår blogginformationssida och vår admin-tilläggssida. Först måste vi ladda upp den artikel som vi redigerar, genom att hämta skivan med Paris: 
 
 $ article = Model :: factory ('Article') -> find_one ($ id); om (! $ artikel instans av artikel) $ app-> notFound (); 
 
Paris skickar ett artikelobjekt som matchar artikelpost-id som mottogs i vår stängning, eller felaktigt om inget existerar. Vi checkar sedan för att se om vi fick en instans tillbaka, om inte vi säger Slim att kasta ett 404-fel.
 
Vi berättar nu Slim för att göra inmatningsmallen, som i vår tilläggsruta, men passerar i det laddade artikelobjektet och rätt åtgärdsadress: 
 
 returnera $ app-> render ('admin_input.html', array ('action_name' => 'Redigera', 'action_url' => '/ admin / edit /'. $ id, 'article' => $ artikel));
 
Vår POST redigeringsväg fungerar nästan identisk med Lägg till rutt, med undantag för att vi måste kontrollera om artikeln skulle kunna laddas innan vi fortsätter och uppdaterar dess attribut: 
 
 $ article = Model :: factory ('Article') -> find_one ($ id); om (! $ artikel instans av artikel) $ app-> notFound ();  $ artikel-> title = $ app-> request () -> post ('title'); $ article-> author = $ app-> request () -> post ("author"); $ article-> summary = $ app-> request () -> post ('summary'); $ article-> content = $ app-> request () -> post ('content'); $ article-> timestamp = date ('Y-m-d H: i: s'); $ Artikel-> Spara (); $ App-> omdirigera ( '/ admin');
 
Vi avslutar vårt admincenter genom att bygga raderingsrutan. Vi gör det genom att först hämta posten, liknande hur vi gjorde på vår bloggdetaljersida tidigare: 
 
 $ article = Model :: factory ('Article') -> find_one ($ id);
 
Om Paris laddade en artikel måste vi ta bort den och sedan skicka tillbaka användaren till huvudadministratörssidan. Paris gör att en post ska raderas så enkelt som möjligt: 
 
 om ($ artikel instanceof artikel) $ article-> delete ();  $ app-> omdirigering ('/ admin');
 
Och med det görs vår grundläggande prototypadministration center.
 
 
 Steg 7: Använda Middleware
 
Vårt administrativa centrum är nu klar. Det är ganska grundläggande eftersom det bara är en prototyp, men vi vill fortfarande ha någon form av auktorisation för att skydda den från nyfikna ögon. Slim tillåter oss att infoga middleware i våra vägar. Vad detta betyder är att vi kan skapa funktioner som kallas innan våra rutter svar stängning gör.
 
Vi kan använda HTTP Basic Auth för att skydda vårt admincenter. Självklart skulle vi använda något lite säkrare på en levande webbplats, men för vår prototyp är det bra. Längst upp på vår sida index.php låt oss skapa två konstanter som innehåller vårt användarnamn och lösenord: 
 
 // Auth Detaljer. definiera ('USERNAME', 'admin'); definiera ("PASSWORD", "lösenord");
 
När vi skapat vår smarta applikationsinstans skapar vi en nedläggning, som vi binder till en variabel för att hålla vår behörighet mellanprogramskontroll: 
 
 // Auth Check. $ authCheck = funktion () använd ($ app) ;
 
Om du aldrig använt HTTP Basic Auth i PHP tidigare är det riktigt enkelt. Vi kan använda $ _SERVER array för att kontrollera vilka referenser som skickades från användarens webbläsare och jämföra dem mot våra konstanter. Vi gör detta inom vår nyskapade stängning. Det första vi behöver göra i vår auth checkfunktion är att få reda på om några autentillbehör har skickats, och om de var, kolla för att se om de matchar våra 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;
 
Allt vi gör här kontrollerar om auth-värdena existerar och matchar, och lagrar resultaten i vissa variabler. Om vi ​​antar att någon av dessa variabler är falsk, vet vi att vi måste uppmana användaren att auktorisera sig själva:
 
 $ app-> response () -> header ("WWW-Authenticate: Basic realm =" Min bloggadministration "," "); $ app-> response () -> header ('HTTP / 1.1 401 Uautoriseret', ''); $ App> svar () -> kroppen (
Ange giltiga administrativa uppgifter
'); $ App> svar () -> skicka (); utgång; 
 
Vi kontrollerar om våra behörighetsuppgifter är okej. Om de inte är det skickar vi ett svar tillbaka med lämpliga rubriker och varningsmeddelanden. Som du såg tidigare kunde vi komma åt objektet Slim Framework Request för att få tillgång till vår POST-data. Vi kan också komma åt det interna svarobjektet, vilket gör det enkelt för oss att trycka in våra rubriker och skriva över Slim Respons Response-kroppen med ett enkelt HTML-varningsmeddelande innan vi äntligen tvingar manuset att gå ut.
 
I Slim kan du lägga till flera callables till en rutt, och de exekveras i den ordning de anges. Vad det innebär är att vi enkelt kan förhindra tillgång till alla våra sträckor genom att lägga till autokontrollen innan svaret stängs: 
 
 // Admin Hem. $ app-> get ('/ admin', $ authCheck, funktion () använd ($ app) //?); // Admin Add. $ app-> get ('/ admin / add', $ authCheck, funktion () använd ($ app) //?); // Admin Add - POST. $ app-> post ('/ admin / add', $ authCheck, funktion () använd ($ app) //?); // Admin Edit. $ app-> get ('/ admin / edit / (id)', $ authCheck, funktion ($ id) användning ($ app) //?); // Admin Edit - POST. $ app-> post ('/ admin / edit / (id)', $ authCheck, funktion ($ id) användning ($ app) //?); // Admin Delete. $ app-> get ('/ admin / delete / (id)', $ authCheck, funktion ($ id) användning ($ app) //?);
 
Och där har du det, vårt admincenter är nu skyddat. Den som försöker komma åt det kommer att se ett varningsmeddelande och bli uppmanad att få sina uppgifter.
  
 
 Steg 8: Sammanfattning
 
Förhoppningsvis har denna handledning visat dig hur snabbt och enkelt det är att få en prototyp igång med en mikroram, ett ORM och malspråk, samtidigt som man behåller god separation av problem och läsbar kod.
 
Ett kraftfullt templerande språk kan förhindra att dina åsikter upphör som en blandning av oläslig PHP- och HTML-spagetti-kod, och hur en flytande ORM kan göra tråkiga CRUD-åtgärder snabbt och smärtfritt.
 
Dessa är bara några av de många coola sakerna du kan göra med Slim, Twig och Paris. Om du gräver ytterligare, kan du lägga till relationer till dina modeller med Paris, lägga till makroutdrag i Twig för att påskynda din mallutveckling och använda namnbaserad routing med Slim för att länka upp ditt webbplatsinnehåll och ändra webbadresser triviala.
 
Glad prototyper och tack så mycket för att läsa!



		
			
	   
	




Koda