I denne artikkelen vil vi dykke dypt inn i Laravel-rammen for å forstå begrepet mellomvare. Første halvdel av artikkelen begynner med en introduksjon til mellomvare og hva den egentlig brukes til.
Når vi går videre, dekker vi hvordan du oppretter egendefinert mellomvare i en Laravel-applikasjon. Etter at du har opprettet egendefinert mellomvare, undersøker vi alternativene som er tilgjengelige for å registrere det med Laravel slik at det faktisk kan påberopes under forespørselsbehandlingsflyten.
Jeg håper at du anser deg kjent med grunnleggende Laravel konsepter og Artisan kommandolinjeverktøyet for å generere stillasekoden. Selvfølgelig kan en arbeidsinstallasjon av den nyeste Laravel-applikasjonen løpe eksemplene i denne artikkelen med en gang.
Vi kan tenke på mellomvare som en mekanisme som gjør at du kan hekte inn i den typiske forespørselsbehandlingsflyten av en Laravel-applikasjon. En typisk Laravel-rutebehandling går gjennom visse stadier av forespørselbehandling, og mellomvare er et av de lagene et program må passere gjennom.
Så hva er poenget med å hekte seg i Laravel-forespørselsbehandlingsflyten? Tenk på noe som krever en utførelse i de tidlige stadiene av oppstart av en applikasjon. For eksempel er det nødvendig å autentisere brukere i de tidlige stadiene for å avgjøre om de har lov til å få tilgang til den nåværende ruten.
Noen ting jeg kunne tenke på at du kunne oppnå gjennom middleware er:
Faktisk sender standard Laravel-applikasjonen allerede et par viktige deler av middleware med den. For eksempel er det mellomvare som kontrollerer om nettstedet er i vedlikeholdsmodus. På den annen side er det mellomvare for å rense innspillingsparametrene. Som nevnt tidligere, oppnås brukergodkjenningen også av selve middleware-enheten.
Jeg håper at forklaringen så langt hjelper deg å føle deg tryggere om begrepet mellomvare. Hvis du fortsatt er forvirret, ikke bekymre deg for det som vi skal bygge et stykke tilpasset mellomvare fra neste avsnitt og utover som skal hjelpe deg å forstå nøyaktig hvordan middleware kan brukes i den virkelige verden.
I denne delen lager vi vår tilpassede mellomvare. Men hva er vår tilpassede mellomvare som skal utføres?
Nylig kom jeg over et egendefinert krav fra klienten min om at hvis brukerne får tilgang til nettstedet fra en hvilken som helst mobil enhet, bør de omdirigeres til den tilsvarende underdomener-URL-en med alle søkeordparametrene intakt. Jeg tror dette er den perfekte brukssaken til å demonstrere hvordan Laravel middleware kan brukes i dette scenariet.
Grunnen til at vi ønsker å bruke mellomvare i dette tilfellet er behovet for å koble til forespørselen flyt av programmet. I vår egendefinerte mellomvare vil vi inspisere brukeragenten, og brukere blir omdirigert til den tilhørende mobilnettadressen hvis de bruker en mobil enhet.
Etter å ha diskutert all den teorien, la oss hoppe inn i selve utviklingen, og det er den beste måten å forstå et nytt konsept, er det ikke?
Som en Laravel-utvikler er det Artisan-verktøyet som du ender med å bruke mesteparten av tiden for å lage grunnleggende malekode hvis du ønsker å lage en tilpasset funksjonalitet. La oss bruke den til å lage en grunnleggende malekode for vår tilpassede mellomvare.
Gå over til kommandolinjen og gå dokumentroten til prosjektet ditt. Kjør følgende kommando for å lage den egendefinerte mellomvaremalen MobileRedirect
.
php artisan make: middleware MobileRedirect
Og det burde skape en fil app / Http / Middleware / MobileRedirect.php
med følgende kode.
Oftere enn ikke, vil du legge merke til implementeringen av
håndtak
metode som fungerer som ryggraden i middleware, og den primære logikken til middleware du ønsker å implementere bør gå her.La meg ta denne muligheten til å introdusere de typer middleware som Laravel kommer med. Hovedsakelig er det to typer - før mellomvare og etter mellomvare.
Som navnet antyder, er før middleware noe som kjører før forespørselen faktisk håndteres og svaret er bygget. På den annen side kjører den etter mellomvare etter at forespørselen er håndtert av søknaden, og svaret er allerede bygget på dette tidspunktet.
I vårt tilfelle må vi omdirigere brukeren før forespørselen håndteres, og derfor vil den bli utviklet som en før middleware.
Gå videre og endre filen
app / Http / Middleware / MobileRedirect.php
med følgende innhold.mobil == "1") retur omdirigering ('mobilnettsted-url-går-her'); returner $ neste ($ forespørsel);For enkelhets skyld, kontrollerer vi bare eksistensen av
mobil
querystring-parameter, og hvis den er satt tilEKTE
, brukeren blir omdirigert til den tilhørende nettadressen til mobilnettstedet. Selvfølgelig vil du bruke brukeragentens deteksjonsbibliotek hvis du ønsker å oppdage det i sanntid.Også, du vil gjerne erstatte
mobil-site-url-går-her
rute med riktig rute eller nettadresse, da det bare er en plassholder for demonstrasjonsformål.Etter vår tilpassede logikk er det et anrop til
$ Neste ($ forespørsel)
som gjør at forespørselen kan behandles videre i søknadskjeden. Det viktige å merke seg i vårt tilfelle er at vi har plassert mobildeteksjonslogikken før$ Neste ($ forespørsel)
ring, effektivt gjør det til før middleware.Og med det er vår tilpassede mellomvare nesten klar til å bli testet. For øyeblikket er det ingen måte Laravel vet om middleware. For å få det til å skje, må du registrere mellomprogramvaren med Laravel-søknaden, og det er akkurat temaet i neste avsnitt.
Før du går inn i neste avsnitt, vil jeg gjerne vise hvordan den etterfølgende middleware ser ut, bare hvis noen der ute er nysgjerrig på det.
Som du allerede hadde lagt merke til, blir den tilpassede logikken til middleware utført etter at forespørselen er behandlet av Laravel-programmet. På denne tiden har du tilgang til
$ svar
objekt også, som lar deg manipulere visse aspekter av det hvis du vil.Så det var historien om etter middleware.
Vår Custom Middleware in Action
Denne delen beskriver prosessen med å registrere mellomprogramvaren med Laravel-applikasjonen slik at den faktisk kunne påberopes under prosessbehandlingsstrømmen.
Gå videre og åpne filen
app / Http / Kernel.php
og se etter følgende utdrag./ ** * Programmets globale HTTP middleware stack. * * Disse mellomvareene kjøres under hver forespørsel til søknaden din. * * @var array * / protected $ middleware = [\ Illuminate \ Foundation \ Http \ Middleware \ CheckForMaintenanceMode :: klasse, \ Illuminate \ Foundation \ Http \ Middleware \ ValidatePostSize :: klasse, \ App \ Http \ Middleware \ TrimStrings :: klasse, \ Illuminate \ Foundation \ Http \ Middleware \ ConvertEmptyStringsToNull :: klasse,];Som du kan se, er
$ mellomvare
inneholder et utvalg av mellomvare som følger med standardinstallasjonen av Laravel. Middleware som er oppført her, vil bli utført på hver Laravel-forespørsel, og dermed er det en ideell kandidat til å plassere vår egen tilpassede mellomvare.Gå videre og ta med vår egendefinerte mellomvare som vist i følgende utdrag.
beskyttet $ middleware = [\ Illuminate \ Foundation \ Http \ Middleware \ CheckForMaintenanceMode :: klasse, \ Illuminate \ Foundation \ Http \ Middleware \ ValidatePostSize :: klasse, \ App \ Http \ Middleware \ TrimStrings :: klasse, \ Illuminate \ Foundation \ Http \ Middleware \ ConvertEmptyStringsToNull :: klasse, \ App \ Http \ Middleware \ MobileRedirect :: klasse,];Prøv nå å få tilgang til noen av Laravel-ruter med spørringen
mobil = 1
, og det bør utløse vår mellomvarekode!Så det er slik du skal registrere din mellomvare som må kjøres på hver forespørsel. Men noen ganger vil du bare kjøre mellomvare for de spesifikke rutene. La oss se hvordan du oppnår det ved å bruke
$ routeMiddleware
.I sammenheng med vårt nåværende eksempel, må vi anta at brukerne vil bli omdirigert til et mobilnettsted hvis de får tilgang til en hvilken som helst bestemt rute på nettstedet ditt. I dette scenariet vil du ikke inkludere mellomvareprogrammet ditt i
$ mellomvare
liste.I stedet vil du legge til mellomvare direkte til rutediagrammet, som vist nedenfor.
Rute :: få ('/ hallo verden', 'HelloWorldController @ index') -> middleware (\ App \ Http \ Middleware \ MobileRedirect :: klasse);Faktisk kan vi gå et skritt videre og lage et alias for middleware, slik at du ikke trenger å bruke inline klassenavn.
Åpne filen
app / Http / Kernel.php
og se etter$ routeMiddleware
som holder mappings av aliaser til mellomvare. La oss ta med oppføringen vår i listen, som vist i følgende utdrag.beskyttet $ routeMiddleware = ['auth' => \ Illuminate \ Auth \ Middleware \ Autentiser :: klasse, 'auth.basic' => \ Lyser \ Auth \ Middleware \ AuthenticateWithBasicAuth :: klasse, 'bindings' => \ Illuminate \ Routing \ Middleware \ SubstituteBindings :: class, 'can' => \ Illuminate \ Auth \ Middleware \ Autorisere :: klasse, 'gjest' => \ App \ Http \ Middleware \ RedirectIfAuthenticated :: klasse, 'gasspjeld' => \ Illuminate \ Routing \ Middleware \ ThrottleRequests :: klasse, 'mobile.redirect' => \ App \ Http \ Middleware \ MobileRedirect :: klasse];Og den reviderte rutediagnosen ser slik ut.
Rute :: få ('/ hallo verden', 'HelloWorldController @ index') -> middleware ('mobile.redirect');Og det er historien om registrering av mellomvare med Laravel-applikasjonen. Det var ganske greit, var det ikke?
Faktisk har vi nådd slutten av denne artikkelen, og jeg håper du har grundig likte det.
Konklusjon
Å utforske arkitektonisk konsept i et hvilket som helst rammeverk er alltid spennende ting, og det var det vi gjorde i denne artikkelen da vi utforsket mellomvare i Laravel-rammeverket.
Fra en grunnleggende introduksjon til mellomvare, flyttet vi vår oppmerksomhet til temaet for å lage tilpasset mellomvare i en Laravel-applikasjon. Og det var sistnevnte halvdel av artikkelen som diskuterte hvordan du registrerer din tilpassede mellomvare med Laravel, og det var også muligheten til å utforske de forskjellige måtene du kunne knytte til middleware.
Forhåpentligvis var reisen fruktbar, og artikkelen har hjulpet deg med å berike din kunnskap. Også, hvis du vil at jeg skal komme opp med bestemte emner i de kommende artiklene, kan du alltid slippe meg en linje om det.
Det er det for i dag, og ikke nøl med å skyte dine spørsmål, om noen, ved hjelp av feedet under!