Laravel tutorial for begyndere

Laravel blev skabt af Taylor Otwell. Siden den første udgivelse i juni 2011 (version 1) er den støt vokset mere og mere populær i PHP-framework-sektoren i webudviklingsindustrien. Meget af denne popularitet kan tilskrives de mange udvikler-førstsindede funktioner, som den kommer med på lager.

Hvorfor Laravel?

Cirka 2000, de fleste PHP koder var proceduremæssigt og kunne findes i form af "scripts", der ville have et sammenfiltret rod af spaghettikode. Selv de simpleste sider havde nej adskillelse af bekymringer, og dermed var det ret nemt for en applikation hurtigt at vokse til et vedligeholdelsesmareridt. Verden havde brug for noget bedre ... Indtast PHP version 5 og en række PHP-frameworks, der forsøger at bringe nogle tiltrængte løsninger og bedre løsninger på forskellige webapplikationsproblemer.

Siden da har vi set mange frameworks frigivet, som ville bane vejen for de populære rammer, der eksisterer og anvendes i dag. I dag ville top tre (efter vores mening) være Zend Framework, Symfony og selvfølgelig Laravel. Selvom hver af disse rammer er baseret på lignende principper og er rettet mod at løse (dybest set) de samme fælles problemer, ligger deres vigtigste forskelle i deres implementeringer. De har hver deres særheder om, hvordan man løser problemer. Når du ser på koden produceret af hver af dem, vil du se, at der er en ret ubrudt linje, der adskiller dem fra hinanden. Efter vores ydmyge mening er Laravel framework det bedste.

Lær mere om Forskellen mellem Laravel og CodeIgniter

Sådan downloades og installeres Laravel med Composer

BEMÆRK Det antages, at du allerede har en kopi af PHP installeret på dit lokale system. Hvis ikke, kan du læse, hvordan du installerer det link.

Composer er både en pakke- og afhængighedsmanager. For at installere det skal du åbne en terminal og cd ind i en ny mappe. Kør denne kommando:

curl -Ss getcomposer.org/installer | php

Resultaterne af denne kommando vil se således ud:

Bemærk For mere omfattende instruktioner om opsætning af Laravel henvises til Laravel-dokumentationen link..

Du vil se det downloade og kompilere composer.phar-scriptet, som er det, vi bruger til at installere Laravel. Selvom der er mange måder at konfigurere en ny Laravel-applikation på, vil vi gøre det via Laravel-komponist-scriptet. For at installere dette script skal du køre:

composer global require laravel/installer

Som kommer til at se sådan ud:

Dette vil downloade og installere alle rammefilerne selv såvel som alle afhængigheder, som det kræver. Pakkerne vil blive gemt i leverandørbiblioteket. Når det først er downloadet og installeret, er det lige så nemt som at udstede følgende kommando:

laravel new uploadApp

Du vil se noget i stil med følgende output:

Composer installerer alle de pakker, som Laravel skal bruge for at køre. Det kan tage et par minutter, så hav tålmodighed. Når det er færdigt, skal du køre en ls -al kommando for at se på, hvad der blev installeret.

Her er en kort oversigt over mapperne i en almindelig Laravel-applikation:

• app/: Dette er kildemappen, hvor vores applikationskode findes. Alle controllere, politikker og modeller er inde i denne mappe
• bootstrap/ : Indeholder applikationens opstartsscript og et par klassekortfiler
• config/: Indeholder appens konfigurationsfiler. Disse ændres normalt ikke direkte, men stoler i stedet på de værdier, der er indstillet i .env-filen (miljø) i roden af ​​appen
• database/: Indeholder databasefilerne inklusive migrationer, frø og testfabrikker
• offentlig/: Offentligt tilgængelig mappe med kompilerede aktiver og selvfølgelig en index.php-fil
• ressourcer/: Indeholder frontend-aktiver såsom javascript-filer, sprogfiler, CSS/SASS-filer og alle skabeloner, der bruges i applikationen (kaldet bladeskabeloner)
• ruter/: Alle ruter i applikationen er inde her. Der er et par forskellige "omfang" af ruter, men den vi vil fokusere på er web.php-filen
• opbevaring/: Alle midlertidige cachefiler, der bruges af applikationen, sessionsfiler, kompilerede visningsscripts og logfiler
• test/: Indeholder testfiler til applikationen såsom enhedstests og funktionelle tests.
• sælger/: Alle afhængighedspakker installeret med composer

Lad os nu bygge resten af ​​appen og køre den med en speciel håndværkerkommando (for at spare os selv for besværet med at installere og konfigurere en webserver som Apache eller nginx). .env-filen indeholder alle de konfigurationsværdier, som filerne i /config-mappen bruger til at konfigurere programmet. Inde i det vil du bemærke, at konfigurationsværdien for forskellige parametre, der bruges af applikationens interne.

Applikationsdesign: En hurtig gennemgang af vores krav

I denne online Laravel-tutorial vil vi bygge en meget enkel applikation, der kun gør to ting:

1. håndtere filuploads fra en webformular
2. visning af de tidligere uploadede filer på en anden side.

Til dette projekt vil vores applikation være skrivebeskyttet, hvilket betyder, at brugeren kun kan skrive filer og se listen over filer, som de har uploadet. Denne applikation er ekstremt grundlæggende, men bør tjene som god praksis for dig at begynde at bygge dine Laravel færdigheder og viden på. Bemærk, at jeg for korthedens skyld har udelukket enhver databasemodellering, migreringer og autentificering, men i en applikation i den virkelige verden er disse yderligere ting, du vil overveje.

Her er en liste over komponenter, som vi skal bruge for at få applikationen til at fungere som forventet:

• A rute som vil tillade omverdenen (internettet) at bruge applikationen samt specificere det endepunkt, der vil pege på, hvor logikken for at gemme den uploadede fil er placeret
• A controller der håndterer anmodningen om at svare flow
• A skabelon som vil blive brugt til at vise en liste over tidligere uploadede filer og selve uploadformularen
• A anmode som den dataansvarlige vil bruge til at validere de data, der er videregivet fra webformularen

Hvad er en rute?

En rute i Laravel er dybest set et slutpunkt specificeret af en URI, der fungerer som en "pegepind" til en eller anden funktionalitet, som applikationen tilbyder. Oftest peger en rute blot på en metode på en controller og dikterer også, hvilke HTTP-metoder der er i stand til at ramme den URI. En rute betyder heller ikke altid controller-metode; det kunne bare videregive eksekveringen af ​​applikationen til en defineret lukning eller anonym funktion.

Hvorfor bruge rute?

Ruter gemmes i filer under mappen /routes inde i projektets rodmappe. Som standard er der et par forskellige filer, der svarer til de forskellige "sider" af applikationen ("sider" kommer fra den sekskantede arkitekturmetodologi). De omfatter:

• web.php De offentlige vendte "browser"-baserede ruter. Disse er de mest almindelige og er det, der bliver ramt af webbrowseren. De kører gennem web-middleware-gruppen og indeholder også faciliteter til csrf beskyttelse (som hjælper med at forsvare sig mod formbaserede ondsindede angreb og hacks) og generelt indeholder en grad af "tilstand" (med dette mener jeg, at de bruger sessioner)
• api.php Ruter, der svarer til en API-gruppe og dermed har API-middlewaren aktiveret som standard. Disse ruter er statsløse og har ingen sessioner eller krydsanmodningshukommelse (én anmodning deler ikke data eller hukommelse med nogen anden anmodning - hver enkelt er selvindkapslet).
• console.php Disse ruter svarer til brugerdefinerede håndværkerkommandoer, som du har oprettet til din app
• channels.php Registrerer ruter til begivenhedsudsendelse

Nøglefilen, der skal bekymre sig om på nuværende tidspunkt, er den browserspecifikke, web.php . Der er allerede en rute defineret som standard, som er den, du rammer rigtigt, når du navigerer til webroden af ​​din applikation (webroden er i den offentlige mappe). Vi skal bruge tre forskellige ruter for at vores upload-applikation kan fungere:

• /upload Dette vil være URI'en på hovedsiden, der viser vores webformular til upload af filer.
• /proces Det er her formularen placeret på /upload-URI'en sender sine formularindsendte data til (formularens "handling")
• /list Dette vil vise alle filer uploadet til webstedet

Bemærk /list-slutpunktet er muligvis ikke nødvendigt, hvis vi ønskede at placere al logikken for at vise uploadformularen og listen over filer på en enkelt side, men vi holdt dem adskilt indtil videre for at tilføje lidt mere sag til emnet. .

//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 denne Laravel-rammevejledning vil vi for hver ønsket rute angive den eksplicit i rutefilen web.php ved hjælp af en af ​​de tilgængelige HTTP-specifikke anmodningsmetoder (get(), post(), put() , delete(), patch() eller options() ). For en oversigt over hver af disse, tjek denne ud. Hvad disse metoder gør, er at specificere, hvilke HTTP-verber der har tilladelse til at få adgang til den givne rute. Hvis du har brug for en rute for at kunne acceptere mere end ét HTTP-verbum (hvilket kan være tilfældet, hvis du bruger en enkelt side til både at vise de oprindelige data og sende indsendte formulardata), kan du bruge Route::any( ) metode.

Det andet argument til både Route::get()- og Route::post()-metoden (og enhver af de andre HTTP-verb-relaterede metoder på rutefacaden), er navnet på en specifik controller og metode, der er indeholdt i den controller, der bliver eksekveret ved at ramme rutens endepunkt med den tilladte HTTP-anmodning (GET, POST, PATCH osv.) Vi bruger UploadController til alle tre ruter og har specificeret dem på følgende måde:

Den sidste metode, vi kalder på hver rute, er dens name() funktion, som accepterer en enkelt streng som et argument og bruges til mere eller mindre at "tagge" en bestemt rute med et navn, der er let at huske (i vores tilfælde, upload, bearbejd og liste). Jeg er klar over, at det ikke virker så fantastisk af en funktion at give hver rute sit eget navn, når URL'en hedder nøjagtigt det samme, men det er virkelig praktisk, når du har en specifik rute som /users/profile/dashboard/config, som ville være nemmere at huske som profil-admin eller bruger-config.

En note om facader:

• Facader giver en "statisk" grænseflade til klasser, der er tilgængelige i applikationens servicebeholder."
• De giver en kortfattet, mindeværdig syntaks, der giver dig mulighed for at bruge Laravels funktioner uden at huske lange klassenavne, der skal injiceres eller konfigureres manuelt.

Ovenstående rutedefinitioner i denne Laravel-rammevejledning, vi bruger rutefacaden i stedet for manuelt at instansiere et nyt Illuminate/Routing/Router-objekt og kalde de tilsvarende metoder på det objekt. Det er bare en genvej, der sparer indtastning. Facader bruges flittigt i hele Laravel-rammen – du kan og bør blive mere fortrolig med dem. Dokumenterne for Facader kan findes link..

Hvad er en controller?

En controller er "C" i "MVC" (Model-View-Controller) arkitekturen, hvilket er det, Laravel er baseret på. En controllers job kan koges ned til denne enkle definition: Den modtager anmodningen fra klienten og returnerer et svar til klienten. Dette er bare-bones-definitionen og er også minimumskravene for enhver given controller. Hvad den gør mellem disse to ting, betragtes generelt som "handlingen" af controlleren (eller "rutens implementering"). Det fungerer som det andet indgangspunkt til applikationen (det første er anmodningen) til klienten, som sender anmodningens nyttelast (som vi kommer til næste gang) til applikationen og forventer en form for svar (i form af en successide, omdirigering, fejlside eller enhver anden form for HTTP-svar).

En controller gør (dybest set) det samme som en rutedefinition med en anonym funktion sat som "handlingen", når den rute rammes. Forskellen er, at en controller holder godt til adskillelsen af ​​bekymringer, mens en rute er defineret inline til den faktiske url-definition, hvilket grundlæggende betyder, at vi kobler rutens tildelte URI med rutens implementering eller den kode, der udføres, når den rute er hit.

For eksempel vil følgende to stykker kode opnå det samme:

Eksempel #1: Rutens definition og implementering i et enkelt metodekald (i web.php-rutefilen)

//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);
});

Eksempel #2: Rutens definition er inde i routes/web.php, men dens implementering ligger i /app/Http/Controllers/HelloWorldController-klassen

//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);
   }
}

Selvom Laravel-eksempel #2 virker som meget mere arbejde (hvilket det ikke er – bare lidt mere kode er alt), så se på de fordele, vi opnår ved at placere vores handlingslogik for den givne "hello-world"-rute inde i en controller i stedet for af med rutens definition som en tilbagekaldsfunktion:

1. Vores logik er rent adskilt i sin egen klasse (adskillelse af bekymringer)
2. Vores controller er sat op til udvidelse senere, hvis vi havde brug for at tilføje yderligere funktioner til den... Lad os sige, at vi måske ville tilføje en "farvel-verden"-funktion... I dette tilfælde ville vi omdøbe controlleren til en mere generisk "HelloController" og derefter definere to separate metoder, Hej() og farvel(). Vi ville også være nødt til at definere to separate ruter, der kortlagde /Hej og / farvel URI'er til deres passende metode på controlleren. Dette er ønskeligt sammenlignet med at opfede en rutefil med hver rutes implementering defineret som tilbagekaldsfunktioner.
3. Laravel har den indbyggede evne til at cache alle rutedefinitionerne i applikationen, så det fremskynder den tid, det tager at finde en given rute (øger applikationens ydeevne); imidlertid du vil kun kunne drage fordel af det, hvis alle dine definerede ruter inde i applikationen er konfigureret ved hjælp af controller-specifikke kortlægninger (se eksempel #2 ovenfor)

Lad os køre denne kommando, der vil generere en ny controller til os.

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

I bund og grund, hvad denne kommando gør, er at generere en stub til en controller ved navn "UploadController" inde i hovedcontrollerbiblioteket på /app/Http/Controllers/UploadController.php. Du er velkommen til at åbne den fil og tage et kig. Det er meget enkelt, fordi det kun er en udtømt version af controlleren, med den korrekte navnerumssti og de påkrævede klasser, som den strækker sig fra.

Generering af anmodningen

Før vi går videre i denne PHP Laravel-tutorial og laver et par ændringer til UploadControllerens genererede stub, tror jeg, det vil give mere mening at oprette anmodningsklassen først. Dette skyldes, at controllermetoden, der håndterer anmodningen, skal skrive hint til anmodningsobjektet i sin signatur, hvilket gør det muligt automatisk at validere de indgående formulardata (som specificeret i regler()-metoden. Mere om det senere...) Lad os nu bruge håndværkerkommandoen igen for at generere vores anmodningsstub:

php artisan make:request UploadFileRequest

Denne kommando genererer en fil kaldet UploadFileRequest inde i app/Http/Requests/UploadFileRequest. Åbn stubben og tag et kig... Du vil finde det meget simpelt, der kun indeholder to metoder, autorisere() og regler.

Oprettelse af valideringslogikken

Lad os ændre anmodningsstubben for at imødekomme behovene i vores applikation. Rediger filen, så den ser sådan ud:

<?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'
       ];
   }
}

Ikke mange ændringer, men læg mærke til, at authorize()-metoden nu returnerer sand i stedet for falsk. Denne metode afgør, om anmodningen skal gå ind i applikationen eller ej. Hvis den er indstillet til falsk, stopper den anmodningen i at komme ind i systemet (hvilket normalt ville være en metode på controlleren). Dette ville være et meget praktisk sted at placere enhver godkendelseskontrol på brugeren eller enhver anden logik, der kan afgøre, om anmodningen kan flyttes videre til controlleren. For nu vender vi bare tilbage her for at tillade alt og alt at bruge anmodningen.

Den anden metode, regler() er, hvor al magien kommer i spil med hensyn til validering. Ideen er enkel: returner et array, der indeholder et sæt regler i form af:

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

Der er mange forskellige valideringsbegrænsninger, der understøttes af Laravel lige ud af boksen. For en komplet liste over dem, tjek onlinedokumentationen link.. Til vores uploadapplikation vil der være to felter, der sendes ind via POST-anmodning fra en formular på frontend. Filnavn-parameteren skal inkluderes inde i formularens krop (dvs. påkrævet) og bruges som det filnavn, vi vil gemme filen under i lageret (det gøres i controlleren – vi kommer til det lidt senere). Vi specificerer også, at filnavnet skal være en streng ved at tilføje et rørtegn (|) og ordet 'streng'. Begrænsninger er altid afgrænset af rør, så du kan angive eventuelle yderligere kriterier for det givne felt på en enkelt linje! Hvilken magt!

Den anden parameter, userFile , er den faktiske fil, som brugeren uploader fra en formular på en webside. UserFile er også påkrævet og skal være en fil. Bemærk: Hvis vi forventede, at den uploadede fil var et billede, ville vi bruge billedbegrænsningen i stedet, hvilket ville begrænse de filtyper, der accepteres til at være en af ​​de populære billedtyper (jpeg, png, bmp, gif eller svg). Da vi ønsker at tillade brugeren at uploade enhver type fil, vil vi bare holde os til filvalideringsbegrænsningen.

Det er omtrent alt, der er til anmodningsobjektet. Dens hovedopgave er blot at holde det acceptable sæt af kriterier (begrænsninger), som formularens kropsparametre skal opfylde for at komme dybere ind i ansøgningen. En anden ting at bemærke er, at disse to felter (brugerFil og filnavn) også skal angives inde i HTML-koden i form af inputfelter (med feltnavnet svarende til navnet inde i anmodningsobjektet).

Du spørger måske: sikker på, at dette definerer karakteristikaene for, hvad en formularanmodning skal indeholde, men hvor foretages den faktiske kontrol af disse begrænsninger? Det kommer vi ind på næste gang.

Ændring af controlleren

Åbn appen/Http/Controllers/UploadController og foretag følgende ændringer 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 er en ret ligetil tilgang til at gemme de uploadede filer på disken. Her er en oversigt over upload()-metoden ovenfor:

• Indtast anmodningsklassen i controllermetoden, der udfører 'kød og kartofler'-funktionaliteten, så vi kan autovalidere de indgående data
• Grib filen ud af det (nu validerede) anmodningsobjekt inde i controllermetoden (i dette tilfælde har vi kaldt det upload(), men det kunne også have fået et mere standardiseret navn som store()).
• Grib filnavnet ud af anmodningen
• Generer det endelige filnavn, der skal bruges til at gemme filen under. GetClientOriginalExtension()-metoden griber simpelthen den originale udvidelse af den uploadede fil.
• Gem filen til det lokale filsystem ved hjælp af dens storeAs()-metode, og indfør den navngivne sti inde i /storage-mappen som det 1. argument og filnavnet, der skal gemmes under som det andet.
• Returner et JSON-svar, der angiver, at anmodningen var vellykket

Bladskabelonen

Den sidste store brik i dette puslespil er bladskabelonen, som vil indeholde al HTML, CSS og javascript til vores simple applikation. Her er koden - vi vil forklare det senere.

<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>

Her er hvad vores / upload siden ser sådan ud:

Dette er et meget typisk eksempel på en blade-fil, der indeholder en HTML-formular og javascript/jQuery til tilføjelse af asynkron funktionalitet (så siden ikke opdateres). Der er en grundlæggende tag uden metodeattribut (som jeg vil forklare på et sekund) og med en nysgerrig handlingsattribut med værdien {{route('file.upload')}}. I blade er dette, hvad der er kendt som en Direktivet. Et direktiv er bare et fancy navn for funktion - de er funktioner, der er specifikke for bladeskabeloner, der udfører forskellige operationer, der er fælles for at konstruere websider og webapplikationer. For en bedre forståelse af alt det fede lort, som blade kan gøre, tjek dokumenterne link.. I ovenstående tilfælde bruger vi rutedirektivet til at generere en URL til vores formularindsendelse.

Husk, at vi definerede vores ruter tidligere i applikationen inde i web.php-filen, og specificerede et let at huske navn for hver af dem. {{route()}}-direktivet accepterer et navn på en rute, slår det op i den internt cachelagrede ruteliste og genererer en fuld URL baseret på definitionen af ​​den rute i web.php-filen. I dette første tilfælde specificerer vi, at vi ønsker, at formularen skal sende de indsendte data til /proces URL'en for vores ansøgning, som er defineret som en POST rute.

Den næste mærkelige ting, du måske har bemærket, er @csrf-tagget lige under åbningsformularmærket. I blade genererer dette tag en _token-parameter på formularen, som bliver tjekket inde i applikationen, før formulardataene får lov til at blive behandlet. Dette sikrer, at dataene i formularen er af en gyldig oprindelse og forhindrer angreb på tværs af websteder med anmodninger om forfalskning. For mere information om dette, se docs.

Efter dette definerer vi vores formular som normal, men bemærk, at navnene på vores formularparametre, userFile og fileName er nøjagtig samme som defineret i vores anmodningsobjekt. Hvis vi glemte at inkludere et input for en given parameter, der var defineret i forespørgselsobjektet (eller stavede det forkert), ville anmodningen mislykkes, og der ville blive returneret en fejl, hvilket forhindrer den oprindelige formularanmodning i nogensinde at ramme controllermetoden placeret på UploadController@ proces.

Gå videre og prøv det og send et par filer til ansøgningen ved hjælp af denne formular. Bagefter skal du navigere til /liste side for at se indholdet af uploadmappen med de filer, du uploadede, anført i en tabel:

Jo større billede

Lad os tage et skridt tilbage og se på, hvad vi har gjort i denne Laravel-tutorial.

Dette diagram viser applikationen, som den står lige nu (detaljer på højt niveau ekskluderet):

Du skal huske på, at det anmodningsobjekt, vi konstruerede i begyndelsen af ​​denne Laravel-tutorial, skal have de samme parametre defineret i dens regelmetode, som er på formularen i bladskabelonen (hvis ikke genlæs afsnittet "Oprettelse af valideringslogikken"). . Brugeren indtaster formularen på en webside, der gengives via en bladeskabelonmotor (denne proces er selvfølgelig på autopilot, så vi behøver ikke engang at tænke på det) og indsender formularen. Skabelonens jQuery-kode nederst stopper standardindsendelsen (som automatisk vil omdirigere til en separat side), opretter en ajax-anmodning, indlæser anmodningen med formulardata og uploader filen og sender det hele til det første lag af vores ansøgning: anmodningen.

Anmodningsobjektet bliver udfyldt ved at knytte parametrene inde i rule()-metoden med de indsendte formularparametre, hvorefter dataene valideres i henhold til hver specificeret regel. Hvis alle reglerne er opfyldt, sendes anmodningen videre til en hvilken som helst controllermetode, der svarer til værdierne defineret i rutefilen web.php. I dette tilfælde er det proces()-metoden for UploadController, der gør arbejdet. Når vi har ramt controlleren, ved vi allerede, at anmodningen bestod valideringen, så vi behøver ikke at teste igen, om det angivne filnavn i virkeligheden er en streng, eller om parameteren userFile faktisk indeholder en type fil... Vi kan fortsætte som normal.

Controllermetoden griber derefter de validerede parametre ud af anmodningsobjektet, genererer et fuldt filnavn ved at sammenkæde parameteren bestået i filnavn med brugerfilens oprindelige udvidelse, gemmer filen i en mappe i vores applikation og returnerer derefter en simpel JSON-kodet svar, der bekræfter, at anmodningen var vellykket. Svaret modtages af jQuery-logikken, som udfører et par flere brugergrænseflade-relaterede opgaver, såsom at vise succes- (eller fejl)-meddelelsen i 5 sekunder og derefter skjule den samt rydde de tidligere formularposter ud ... dette er så brugeren ved sikker på, at anmodningen var vellykket og kan uploade en anden fil, hvis de ønsker det.

Bemærk også i diagrammet ovenfor, hvor linjen er trukket mellem klienten og serveren. Dette koncept er helt afgørende for dig at forstå og vil hjælpe dig med at løse problemer og problemer, du måtte have i fremtiden, når du for eksempel jonglerer med flere asynkrone anmodninger, der kan opstå på ethvert givet tidspunkt. Adskillelsen er lige ved grænsen af ​​anmodningsobjektet. Selve anmodningsobjektet kan opfattes som "gatewayen" til resten af ​​applikationen... Det udfører den indledende validering og registrering af formularværdier, der sendes ind fra webbrowseren. Hvis de anses for gyldige, så fortsætter det til den registeransvarlige. Alt før det er på forsiden (“klienten” betyder bogstaveligt talt “på brugerens computer”). Svaret returneres fra appen tilbage til klientsiden, hvor vores jQuery-kode tålmodigt lytter efter dens ankomst og udfører et par enkle UI-opgaver, når den modtager den.

Vi har dækket næsten 90+ vigtige ofte stillede spørgsmål Laravel og PHP-relaterede interviewspørgsmål for friske såvel som erfarne kandidater til at få det rigtige job.