Laravel handledning för nybörjare

Laravel skapades av Taylor Otwell. Sedan den första lanseringen i juni 2011 (version 1) har den stadigt vuxit mer och mer populär inom PHP-framework-sektorn inom webbutvecklingsindustrin. Mycket av denna popularitet kan tillskrivas de många utvecklare-först-mindade funktioner som den kommer med lager.

Varför Laravel?

Cirka 2000, de flesta PHP-koder var procedurmässigt och kunde hittas i form av "manus" som skulle ha en trasslig röra av spagettikod. Även de enklaste sidorna hade nej dela upp problemen, och därför var det ganska lätt för en applikation att snabbt växa till en underhållsmardröm. Världen behövde något bättre ... Gå in i PHP version 5 och en mängd olika PHP-ramverk för att försöka få fram lite välbehövlig lösning och bättre lösningar på olika problem med webbapplikationer.

Sedan dess har vi sett många ramverk släppts som skulle bana väg för de populära ramverk som finns och används idag. I dag skulle topp tre (enligt vår mening) vara Zend Framework, Symfony och såklart Laravel. Även om vart och ett av dessa ramverk grundades på liknande principer och är inriktade på att lösa (i princip) samma gemensamma problem, ligger deras viktigaste skillnader i implementeringen. De har alla sina egenheter om hur man ska gå till väga för att lösa problem. När du tittar på koden som produceras av var och en av dem kommer du att se att det finns en ganska heldragen linje som skiljer dem från varandra. Enligt vår ödmjuka åsikt är Laravel-ramverket det bästa.

Läs mer om Skillnaden mellan Laravel och CodeIgniter

Hur man laddar ner och installerar Laravel med Composer

ANMÄRKNINGAR Det antas att du redan har en kopia av PHP installerat på ditt lokala system. Om inte kan du läsa hur du installerar det här.

Composer är både en paket- och beroendehanterare. För att installera det, öppna en terminal och cd till en ny katalog. Kör detta kommando:

curl -Ss getcomposer.org/installer | php

Resultaten av detta kommando kommer att se ut så här:

Anmärkningar För mer utförliga instruktioner om hur du installerar Laravel, se Laravel-dokumentationen här..

Du kommer att se att det laddar ner och kompilerar skriptet composer.phar, vilket är vad vi använder för att installera Laravel. Även om det finns många sätt att ställa in en ny Laravel-applikation, kommer vi att göra det via Laravels kompositörsskript. För att installera det här skriptet, kör:

composer global require laravel/installer

Som kommer att se ut ungefär så här:

Detta kommer att ladda ner och installera alla ramfiler själva såväl som alla beroenden som det kräver. Paketen kommer att sparas i leverantörskatalogen. När det väl har laddats ner och installerat är det lika enkelt som att utfärda följande kommando:

laravel new uploadApp

Du kommer att se något i stil med följande utdata:

Composer installerar alla paket som Laravel behöver för att kunna köras. Det kan ta några minuter så ha tålamod. När det är klart, kör ett ls -al-kommando för att ta en titt på vad som installerades.

Här är en kort sammanfattning av katalogerna i en vanlig Laravel-applikation:

• app/ : Det här är källmappen där vår applikationskod finns. Alla kontroller, policyer och modeller finns i den här mappen
• bootstrap/ : Innehåller programmets startskript och några klasskartfiler
• config/ : Innehåller appens konfigurationsfiler. Dessa ändras vanligtvis inte direkt utan förlitar sig istället på de värden som ställs in i filen .env (miljö) i roten av appen
• databas/ : Inrymmer databasfilerna inklusive migrationer, frön och testfabriker
• offentlig/ : Allmänt tillgänglig mapp som innehåller kompilerade tillgångar och naturligtvis en index.php-fil
• Resurser/ : Innehåller front-end-tillgångar som javascript-filer, språkfiler, CSS/SASS-filer och alla mallar som används i applikationen (kallade bladmallar)
• rutter/ : Alla rutter i applikationen finns här inne. Det finns några olika "omfattningar" av rutter men den vi kommer att fokusera på är web.php-filen
• lagring/ : Alla temporära cachefiler som används av programmet, sessionsfiler, kompilerade vyskript och loggfiler
• tester/: Innehåller testfiler för applikationen såsom enhetstester och funktionstester.
• Säljare/ : Alla beroendepaket installerade med composer

Låt oss nu bygga resten av appen och köra den med ett speciellt hantverkskommando (för att spara oss besväret med att installera och konfigurera en webbserver som Apache eller nginx). .env-filen innehåller alla konfigurationsvärden som filerna i katalogen /config använder för att konfigurera programmet. Inuti den kommer du att märka att konfigurationsvärdet för olika parametrar som används av applikationens interna delar.

Applikationsdesign: En snabb genomgång av våra krav

I denna online Laravel-handledning kommer vi att bygga en mycket enkel applikation som bara kommer att göra två saker:

1. hantera filuppladdningar från ett webbformulär
2. visar de tidigare uppladdade filerna på en annan sida.

För detta projekt kommer vår applikation att vara skrivbara, vilket innebär att användaren bara kan skriva filer och se listan över filer som de har laddat upp. Denna applikation är extremt grundläggande men bör fungera som god praxis för dig att börja bygga dina Laravel-färdigheter och kunskaper på. Observera att jag för korthetens skull har uteslutit all databasmodellering, migrering och autentisering, men i en verklig applikation är dessa ytterligare saker du vill överväga.

Här är en lista över komponenter som vi behöver för att få applikationen att fungera som förväntat:

• A rutt som gör det möjligt för omvärlden (internet) att använda applikationen samt ange slutpunkten som pekar på var logiken för att spara den uppladdade filen finns
• A styrenhet som hanterar begäran om svarsflöde
• A mall som kommer att användas för att visa en lista över tidigare uppladdade filer och själva uppladdningsformuläret
• A begära som den registeransvarige kommer att använda för att validera de uppgifter som skickas in från webbformuläret

Vad är en rutt?

En rutt i Laravel är i grunden en slutpunkt specificerad av en URI som fungerar som en "pekare" till någon del av funktionalitet som erbjuds av applikationen. Vanligtvis pekar en rutt helt enkelt på en metod på en styrenhet och dikterar även vilka HTTP-metoder som kan träffa den URI:n. En rutt betyder inte alltid kontrollmetoden heller; det kan bara skicka exekveringen av applikationen till en definierad stängning eller anonym funktion också.

Varför använda Route?

Rutter lagras i filer under mappen /routes i projektets rotkatalog. Som standard finns det några olika filer som motsvarar de olika "sidorna" av applikationen ("sidor" kommer från den hexagonala arkitekturmetoden). De inkluderar:

• web.php Den publik som står inför "webbläsare"-baserade rutter. Dessa är de vanligaste och är det som drabbas av webbläsaren. De går genom webbmellanvarugruppen och innehåller även faciliteter för csrf-skydd (vilket hjälper till att försvara sig mot formbaserade skadliga attacker och hacks) och generellt innehåller en grad av "tillstånd" (med detta menar jag att de använder sessioner)
• api.php Rutter som motsvarar en API-grupp och därmed har API-mellanvaran aktiverad som standard. Dessa rutter är tillståndslösa och har inga sessioner eller minne för korsförfrågningar (en begäran delar inte data eller minne med någon annan begäran – var och en är självinkapslad).
• console.php Dessa rutter motsvarar anpassade hantverkarkommandon som du har skapat för din app
• channels.php Registrerar rutter för evenemangssändning

Nyckelfilen att tänka på för närvarande är den webbläsarspecifika, web.php . Det finns redan en rutt definierad som standard, vilket är den du träffar direkt när du navigerar till webbroten för din applikation (webroten finns i den offentliga katalogen). Vi kommer att behöva tre olika vägar för att vår uppladdningsapplikation ska fungera:

• /upload Detta kommer att vara URI:n för huvudsidan som visar vårt webbformulär för uppladdning av filer.
• /process Detta kommer att vara där formuläret som finns på /upload URI:n skickar sina formulärinskickade data till (formulärets "åtgärd")
• /list Detta kommer att lista alla filer som laddats upp till webbplatsen

Notera /list-slutpunkten kanske inte behövs om vi vill lägga all logik för att visa uppladdningsformuläret och listan med filer på en enda sida, men vi höll dem åtskilda för nu för att lägga till lite mer materia till det aktuella ämnet .

//inside routes/web.php
Route::get('/upload', 'UploadController@upload')->name('upload');
Route::get('/download, 'UploadController@download)->name(‘download');
Route::post('/process', 'UploadController@process')->name('process');
Route::get('/list', 'UploadController@list')->name('list');

I denna handledning för Laravel-ramverket, för varje önskad rutt, kommer vi att lista den explicit i ruttfilen web.php med hjälp av en av de tillgängliga HTTP-specifika begäransmetoderna (get(), post(), put() , delete(), patch() eller options() ). För en uppdelning av var och en av dessa, kontrollera detta ut. Vad dessa metoder gör är att specificera vilka HTTP-verb som tillåts komma åt den givna rutten. Om du behöver en rutt för att kunna acceptera mer än ett HTTP-verb (vilket kan vara fallet om du använder en enskild sida för att både visa de ursprungliga uppgifterna och skicka inskickade formulärdata), kan du använda Route::any( ) metod.

Det andra argumentet till både Route::get() och Route::post()-metoden (och någon av de andra HTTP-verb-relaterade metoderna på Route-fasaden), är namnet på en specifik Controller och metod som finns inuti den kontroller som exekveras när man träffar ruttens slutpunkt med den tillåtna HTTP-begäran (GET, POST, PATCH, etc.) Vi använder UploadController för alla tre rutter och har specificerat dem på följande sätt:

Den sista metoden vi anropar på varje rutt är dess name() funktion, som accepterar en enda sträng som ett argument och används för att mer eller mindre "tagga" en viss rutt med ett lätt att komma ihåg namnet (i våra fall, ladda upp, bearbeta och lista). Jag inser att det inte verkar vara en så bra funktion att ge varje rutt ett eget namn när URL:en heter exakt samma, men det är verkligen praktiskt när du har en specifik rutt som /users/profile/dashboard/config, vilket skulle vara lättare att komma ihåg som profile-admin eller user-config.

En anteckning om fasader:

• Fasader ger ett "statiskt" gränssnitt till klasser som är tillgängliga i applikationens servicebehållare."
• De ger en kortfattad, minnesvärd syntax som låter dig använda Laravels funktioner utan att komma ihåg långa klassnamn som måste injiceras eller konfigureras manuellt.

Ovanstående ruttdefinitioner i denna Laravel-ramverkshandledning använder vi ruttfasaden istället för att manuellt instansiera ett nytt Illuminate/Routing/Router-objekt och anropa motsvarande metoder för det objektet. Det är bara en genväg som sparar skrivning. Fasader används flitigt i hela Laravels ramverk – du kan och bör bli mer bekant med dem. Dokumenten för Fasader finns här..

Vad är en controller?

En kontroller är "C" i "MVC" (Model-View-Controller)-arkitekturen, vilket är vad Laravel bygger på. En controllers jobb kan kokas ner till denna enkla definition: Den tar emot begäran från klienten och returnerar ett svar till klienten. Detta är bara-bones-definitionen och är också minimikraven för en given kontrollant. Vad den gör mellan dessa två saker betraktas generellt som kontrollantens "åtgärd" (eller "ruttens implementering"). Den fungerar som den andra ingångspunkten till applikationen (den första är begäran) till klienten, som skickar förfrågans nyttolast (som vi kommer till härnäst) till applikationen och förväntar sig någon typ av svar (i form av en framgångssida, omdirigering, felsida eller någon annan typ av HTTP-svar).

En styrenhet gör (i princip) samma sak som en ruttdefinition med en anonym funktion inställd som "åtgärd" när den rutten träffas. Skillnaden är att en styrenhet klarar separeringen av problem medan en rutt är definierad i linje med den faktiska URL-definitionen, vilket i princip betyder att vi kopplar ruttens tilldelade URI med ruttens implementering, eller koden som körs när den rutten är träffa.

Till exempel kommer följande två kodbitar att uppnå samma sak:

Exempel #1: Ruttens definition och implementering i ett enda metodanrop (i filen web.php routes)

//inside routes/web.php
<?php
Route::get('/hello-world', function(Request $request) {
   $name = $request->name;
   return response()->make("<h1>Hello World! This is ".$name, 200);
});

Exempel #2: Ruttens definition är inuti routes/web.php, men dess implementering finns i klassen /app/Http/Controllers/HelloWorldController

//inside routes/web.php
<?php

Route::get('/hello-world', 'HelloWorldController@index')->name('hello-world');

------------------------------------------------------------------------------------
//inside app/Http/Controllers/HelloWorldController.php
<?php
namespace App\Http\Controllers;
use Illuminate\Http\Request;

class HelloWorldController extends Controller
{
   public function index(Request $request)
   {
       $name = $request->name;
       return response()->make("<h1>Hello World! This is ".$name, 200);
   }
}

Även om Laravel-exempel #2 verkar vara mycket mer arbete (vilket det inte är – bara lite mer kod är allt), titta på fördelarna vi vinner genom att placera vår handlingslogik för den givna "hej-världen"-rutten inuti en kontroller istället av med ruttens definition som en återuppringningsfunktion:

1. Vår logik är rent uppdelad i sin egen klass (separation av bekymmer)
2. Vår styrenhet är inställd för förlängning senare om vi behövde lägga till ytterligare funktioner till den... Säg att vi kanske ville lägga till en "goodbye-world"-funktion... I det här fallet skulle vi byta namn på kontrollern till en mer generisk "HelloController" och sedan definiera två separata metoder, Hallå() och adjö(). Vi skulle också behöva definiera två separata rutter som kartlade /Hallå och / adjö URI:er till deras lämpliga metod på styrenheten. Detta är önskvärt jämfört med att göda upp en ruttfil med varje rutts implementering definierad som återuppringningsfunktioner.
3. Laravel har den inbyggda förmågan att cachelagra alla ruttdefinitioner i applikationen så att den snabbar upp tiden det tar att hitta en given rutt (ökar applikationens prestanda); emellertid du kommer bara att kunna dra fördel av det om alla dina definierade rutter i applikationen är konfigurerade med hjälp av styrenhetsspecifika mappningar (se exempel #2 ovan)

Låt oss köra det här kommandot som genererar en ny styrenhet åt oss.

// ...inside the project's root directory:
php artisan make:controller UploadController   

Vad det här kommandot gör är att generera en stubb för en kontroller som heter "UploadController" i huvudkontrollkatalogen på /app/Http/Controllers/UploadController.php. Öppna gärna den filen och ta en titt. Det är väldigt enkelt eftersom det bara är en avstängd version av kontrollern, med rätt namnområdessökväg och de obligatoriska klasserna som den sträcker sig från.

Genererar förfrågan

Innan vi går vidare i denna PHP Laravel-handledning och gör några ändringar i UploadControllerns genererade stubb, tror jag att det kommer att vara mer meningsfullt att skapa förfrågningsklassen först. Detta beror på att kontrollmetoden som hanterar begäran måste skriva hint begäranobjektet i sin signatur, vilket gör det möjligt för den att automatiskt validera inkommande formulärdata (enligt reglernas metod. Mer om det senare...) Låt oss nu använda kommandot hantverkare igen för att generera vår förfrågningsstubb:

php artisan make:request UploadFileRequest

Detta kommando genererar en fil som heter UploadFileRequest inuti app/Http/Requests/UploadFileRequest. Öppna stubben och ta en titt... Du kommer att tycka att det är väldigt enkelt och innehåller bara två metoder, authorize() och regler.

Skapar valideringslogiken

Låt oss ändra förfrågningsstubben för att möta behoven i vår applikation. Ändra filen så att den ser ut så här:

<?php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

class UploadFileRequest extends FormRequest
{
   /**
    * Determine if the user is authorized to make this request.
    *
    * @return bool
    */
   public function authorize()
   {
       return true;
   }

   /**
    * Get the validation rules that apply to the request.
    *
    * @return array
    */
   public function rules()
   {
       return [
           'fileName' => 'required|string',
           'userFile' => 'required|file'
       ];
   }
}

Inte många ändringar men lägg märke till att authorize()-metoden nu returnerar true istället för false. Den här metoden avgör om begäran ska gå in i applikationen eller inte. Om den är inställd på false, stoppar den begäran från att komma in i systemet (vilket normalt skulle vara en metod på styrenheten). Detta skulle vara ett mycket praktiskt ställe att placera eventuella auktoriseringskontroller på användaren eller någon annan logik som kan avgöra om begäran kan flyttas vidare till styrenheten. För nu återvänder vi bara sant här för att tillåta allt och allt att använda begäran.

Den andra metoden, rules() är där all magi spelar in när det gäller validering. Tanken är enkel: returnera en array som innehåller en uppsättning regler i form av:

'formFieldName' => 'constraints this field has separated by pipe characters (|)'

Det finns många olika valideringsbegränsningar som stöds av Laravel direkt. För en fullständig lista över dem, kolla in onlinedokumentationen här.. För vår uppladdningsapplikation kommer det att finnas två fält som skickas in via POST-begäran från ett formulär på frontend. Parametern fileName måste ingå i formulärets brödtext (dvs. obligatoriskt) och används som filnamnet vi kommer att lagra filen under i lagringen (detta görs i kontrollern – vi kommer till det lite senare). Vi specificerar också att filnamnet måste vara en sträng genom att lägga till ett piptecken (|) och ordet 'sträng'. Restriktioner är alltid avgränsade av rör, vilket gör att du kan ange eventuella ytterligare kriterier för det givna fältet på en enda rad! Vilken kraft!

Den andra parametern, userFile , är den faktiska filen som användaren laddar upp från ett formulär på en webbsida. UserFile krävs också och måste vara en fil. Obs: Om vi ​​förväntade oss att den uppladdade filen skulle vara en bild, skulle vi istället använda bildbegränsningen, vilket skulle begränsa de filtyper som accepteras till att vara en av de populära bildtyperna (jpeg, png, bmp, gif eller svg). Eftersom vi vill tillåta användaren att ladda upp vilken typ av fil som helst, kommer vi bara att hålla oss till begränsningen för filvalidering.

Det är ungefär allt som finns i förfrågningsobjektet. Dess huvudsakliga uppgift är att helt enkelt hålla den acceptabla uppsättningen av kriterier (begränsningar) som formulärets kroppsparametrar måste uppfylla för att gå djupare in i ansökan. En annan sak att notera är att dessa två fält (userFile och filnamn) också måste anges i HTML-koden i form av inmatningsfält (med fältnamnet som motsvarar namnet inuti förfrågningsobjektet).

Du kanske frågar: visst definierar detta egenskaperna för vad en formulärförfrågan ska innehålla, men var görs den faktiska kontrollen av dessa begränsningar? Vi kommer in på det härnäst.

Ändra styrenheten

Öppna appen/Http/Controllers/UploadController och gör följande ändringar i den:

<?php

namespace App\Http\Controllers;

use Illuminate\Contracts\Container\BindingResolutionException;
use Illuminate\Http\Request;
use App\Http\Requests\UploadFileRequest; //our new request class
use Illuminate\Support\Facades\Storage; 

class UploadController extends Controller
{
   /**
    * This is the method that will simply list all the files uploaded by name and provide a
    * link to each one so they may be downloaded
    *
    * @param $request : A standard form request object
    * @return \Illuminate\Contracts\View\Factory|\Illuminate\View\View
    * @throws BindingResolutionException
    */
   public function list(Request $request)
   {
       $uploads = Storage::allFiles('uploads');

       return view('list', ['files' => $uploads]);
   }

   /**
    * @param $file
    * @return \Symfony\Component\HttpFoundation\BinaryFileResponse
    * @throws BindingResolutionException
    */
   public function download($file)
   {
       return response()->download(storage_path('app/'.$file));
   }

   /**
    * @return \Illuminate\Contracts\View\Factory|\Illuminate\View\View
    * @throws BindingResolutionException
    */
   public function upload()
   {
       return view('upload');
   }

   /**
    * This method will handle the file uploads. Notice that the parameter's typehint
    * is the exact request class we generated in the last step. There is a reason for this!
    *
    * @param $request : The special form request for our upload application
    * @return array|\Illuminate\Http\UploadedFile|\Illuminate\Http\UploadedFile[]|null
    * @throws BindingResolutionException
    */
   public function store(UploadFileRequest $request)
   {
       //At this point, the parameters passed into the $request (from form) are
       //valid--they satisfy each of the conditions inside the rules() method

       $filename = $request->fileName;    //parameters have already been validated
       $file = $request->file('userFile'); //that we don't need any additional isset()

       $extension = $file->getClientOriginalExtension(); //grab the file extension
       $saveAs = $filename . "." . $extension; //filename to save file under

       $file->storeAs('uploads', $saveAs, 'local'); //save the file to local folder

       return response()->json(['success' => true]); //return a success message
   }
}

Så det är en ganska enkel metod att spara de uppladdade filerna på disken. Här är en uppdelning av upload()-metoden ovan:

• Ange begäranklassen i kontrollmetoden som gör funktionen "kött och potatis" så att vi kan autovalidera inkommande data
• Ta bort filen från det (nu validerade) förfrågningsobjektet i kontrollmetoden (i det här fallet har vi döpt det till upload() men det kunde också ha fått ett mer standardiserat namn som store()).
• Ta bort filnamnet från begäran
• Generera det slutliga filnamnet som kommer att användas för att spara filen under. Metoden getClientOriginalExtension() tar helt enkelt tag i den ursprungliga förlängningen av den uppladdade filen.
• Lagra filen i det lokala filsystemet med hjälp av dess storeAs()-metod, och skicka in den namngivna sökvägen inuti /storage-katalogen som det första argumentet och filnamnet att spara den under som det andra.
• Returnera ett JSON-svar som indikerar att begäran lyckades

Bladmallen

Den sista stora biten i detta pussel är bladmallen, som kommer att innehålla all HTML, CSS och javascript för vår enkla applikation. Här är koden – vi kommer att förklara den senare.

<body>
   <h1>Upload a file</h1>
   <form id="uploadForm" name="uploadForm" action="{{route('upload')}}" enctype="multipart/form-data">
       @csrf
       <label for="fileName">File Name:</label>
       <input type="text" name="fileName" id="fileName" required /><br />
       <label for="userFile">Select a File</label>
       <input type="file" name="userFile" id="userFile" required />
       <button type="submit" name="submit">Submit</button>
   </form>
   <h2 id="success" style="color:green;display:none">Successfully uploaded file</h2>
   <h2 id="error" style="color:red;display:none">Error Submitting File</h2>
   <script src="//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>
   <script>
        $('#uploadForm').on('submit', function(e) {
            e.preventDefault();
            var form = $(this);
            var url = form.attr('action');
            $.ajax({
                url: url,
                type: "POST",
                data: new FormData(this),
                processData: false,
                contentType: false,
                dataType: "JSON",
                success: function(data) {
                    $("#fileName").val("");
                    $("#userFile").val("");
                }
            }).done(function() {
                $('#success').css('display', 'block');
                window.setTimeout(()=>($("#success").css('display', 'none')), 5000);
            }).fail(function() {
                $('#error').css('display', 'block');
                window.setTimeout(()=>($("#error").css('display', 'none')), 5000);
            });
        });
   </script>
</body>
</html>

Här är vad vår /ladda upp sidan ser ut så här:

Detta är ett mycket typiskt exempel på en bladfil som innehåller ett HTML-formulär och javascript/jQuery för att lägga till asynkron funktionalitet (så att sidan inte uppdateras). Det finns en grundläggande tagg utan metodattribut (vilket jag ska förklara på bara en sekund) och med ett kuriöst åtgärdsattribut med värdet {{route('file.upload')}}. I blad är detta vad som kallas en Direktiv. Ett direktiv är bara ett fint namn på funktion – de är funktioner specifika för bladmallar som utför olika operationer som är vanliga för att konstruera webbsidor och webbapplikationer. För en bättre förståelse för allt coolt som blade kan göra, kolla in dokumenten här.. I fallet ovan använder vi ruttdirektivet för att generera en URL för vårt formulär.

Kom ihåg att vi definierade våra rutter tidigare i applikationen i web.php-filen, och angav ett lätt att komma ihåg namnet för var och en av dem. Direktivet {{route()}} accepterar ett namn på en rutt, slår upp det i den internt cachade ruttlistan och genererar en fullständig URL baserat på definitionen av den rutten i web.php-filen. I det här första fallet anger vi att vi vill att formuläret ska skicka inskickade data till /process URL för vår ansökan, som definieras som en POST rutt.

Nästa konstiga sak du kanske har lagt märke till är @csrf-taggen precis under den inledande formulärtaggen. I blade genererar denna tagg en _token-parameter på formuläret, som kontrolleras i applikationen innan formulärdata tillåts bearbetas. Detta säkerställer att informationen i formuläret är av ett giltigt ursprung och förhindrar förfalskningsattacker mellan webbplatser. För mer information om detta, se docs.

Efter detta definierar vi vårt formulär som normalt, dock notera att namnen på våra formulärparametrar, användarfil och filnamn är exakt Sami som definieras i vårt förfrågningsobjekt. Om vi ​​glömde att inkludera en indata för en given parameter som definierades i förfrågningsobjektet (eller felstavade det), skulle begäran misslyckas och ett fel skulle returneras, vilket förhindrar att den ursprungliga formulärförfrågan någonsin träffar kontrollmetoden som finns på UploadController@ bearbeta .

Varsågod och prova det och skicka in några filer till ansökan med det här formuläret. Efteråt, navigera till /lista sida för att se innehållet i uppladdningsmappen, med filerna du laddade upp listade i en tabell:

Den större bilden

Låt oss ta ett steg tillbaka och titta på vad vi har gjort i denna Laravel-handledning.

Det här diagrammet visar applikationen som den ser ut just nu (detaljer på hög nivå exkluderas):

Du bör komma ihåg att förfrågningsobjektet som vi konstruerade i början av denna Laravel-handledning bör ha samma parametrar definierade i dess regelmetod som finns i formuläret i bladmallen (om inte läs avsnittet "Skapa valideringslogiken") igen. . Användaren anger formuläret på en webbsida som renderas via en bladmallsmotor (denna process är givetvis på autopilot så vi behöver inte ens tänka på det) och skickar in formuläret. Mallens jQuery-kod längst ner stoppar standardinlämningen (som automatiskt skulle omdirigera till en separat sida), skapar en ajax-förfrågan, laddar förfrågan med formulärdata och laddar upp filen och skickar det hela till det första lagret av vår ansökan: begäran.

Begäran-objektet fylls i genom att associera parametrarna i rule()-metoden med de inskickade formulärparametrarna, och validerar sedan data enligt varje specificerad regel. Om alla regler är uppfyllda, skickas begäran vidare till vilken kontrollmetod som helst som motsvarar värdena definierade i ruttfilen web.php. I det här fallet är det process()-metoden för UploadController som gör jobbet. När vi väl träffar kontrollern vet vi redan att begäran godkändes valideringen så vi behöver inte testa om det angivna filnamnet i själva verket är en sträng eller om parametern userFile faktiskt innehåller någon typ av fil... Vi kan fortsätta som vanligt.

Styrmetoden tar sedan tag i de validerade parametrarna ur förfrågningsobjektet, genererar ett fullständigt filnamn genom att sammanfoga parametern som skickats in filnamn med användarfilens ursprungliga tillägg, lagrar filen i en katalog i vår applikation och returnerar sedan en enkel JSON-kodad svar som verifierar att begäran lyckades. Svaret tas emot av jQuery-logiken, som gör några fler UI-relaterade uppgifter som att visa framgångsmeddelandet (eller felmeddelandet) i 5 sekunder och sedan dölja det samt rensa bort tidigare formulärposter...detta är så att användaren vet säker på att begäran lyckades och kan ladda upp en annan fil, om de vill.

Notera också i diagrammet ovan precis var linjen dras mellan klienten och servern. Det här konceptet är helt avgörande för att du ska förstå och kommer att hjälpa dig att lösa problem och problem du kan ha i framtiden när du jonglerar, till exempel, flera asynkrona förfrågningar som kan uppstå vid varje given tidpunkt. Separationen är precis vid gränsen för förfrågningsobjektet. Själva förfrågningsobjektet kan ses som "gatewayen" till resten av applikationen... Det gör den första valideringen och registreringen av formulärvärden som skickas in från webbläsaren. Om de bedöms vara giltiga, går det vidare till den registeransvarige. Allt innan dess finns på fronten (”klienten” betyder bokstavligen ”på användarens dator”). Svaret returneras från appen tillbaka till klientsidan, där vår jQuery-kod tålmodigt lyssnar efter dess ankomst och gör några enkla UI-uppgifter när den väl tar emot den.

Vi har täckt nästan 90+ viktiga vanliga frågor Laravel och PHP-relaterade intervjufrågor för nyblivna såväl som erfarna kandidater för att få rätt jobb.