Laravel tutorial for begyndere

Hvad er Laravel?

Laravel er en open source web-MVC-ramme til PHP. Laravel er en robust ramme, der giver nem udvikling af PHP-webapplikationer med funktioner som et modulært pakkesystem med en dedikeret afhængighedsmanager, adgang til relationelle databaser og andre hjælpeprogrammer til applikationsimplementering og vedligeholdelse.

Laravel blev skabt af Taylor Otwell. Siden den første udgivelse i juni 2011 (version 1) er den støt blevet mere og mere populær inden for PHP-framework-sektoren i webudviklingsbranchen. Meget af denne popularitet kan tilskrives de mange udviklerorienterede funktioner, som den leveres med som standard.

Hvorfor Laravel?

Cirka 2000, de fleste PHP kode 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 udvikle sig til et vedligeholdelsesmareridt. Verden havde brug for noget bedre. Mød PHP version 5 og en række PHP-frameworks, der forsøgte at bringe en tiltrængt struktur og bedre løsninger på forskellige webapplikationsproblemer.

Siden da har vi set mange udgivelser af frameworks, der banede vejen for de populære frameworks, der bruges i dag. I dag er de tre bedste (efter vores mening) Zend Framework, Symfony og selvfølgelig Laravel. Selvom hvert af disse frameworks er baseret på lignende principper og er rettet mod at løse (grundlæggende) de samme fælles problemer, ligger deres vigtigste forskelle i deres implementeringer. De har hver især deres egne særheder i forhold til, hvordan man løser problemer. Når man ser på den kode, der er produceret af hver af dem, vil man se, at der er en ret solid linje, der adskiller dem fra hinanden. Efter vores ydmyge mening er Laravel-frameworket det bedste.

Lær mere om forskellen mellem Laravel og Codetændsats.

Sådan downloades og installeres Laravel med Composer

Bemærk: Denne vejledning blev skrevet til Laravel 5.8, men routing-, controller-, request- og Blade-koncepterne forbliver de samme i nuværende udgivelser. Fra 2026 er den seneste version Laravel 13 (udgivet marts 2026), som kræver PHP 8.3 eller nyere, mens Laravel 12 kræver PHP 8.2.

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, se Laravel-dokumentationen link..

Du vil se den downloade og kompilere composer.phar-scriptet, som er det, vi bruger til at installere Laravel. Selvom der er adskillige måder at konfigurere en ny Laravel-applikation på, gør vi det via Laravel composer-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 selve framework-filerne samt alle de afhængigheder, det kræver. Pakkerne gemmes i leverandørmappen. Når det er downloadet og installeret, er det så nemt som at udføre 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å vær tålmodig. Når det er færdigt, skal du køre en ls -al-kommando for at se, 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 findes i denne mappe.
• bootstrap/ : Indeholder programmets opstartsskript og et par klassekortfiler.
• config/: Indeholder appens konfigurationsfiler. Disse ændres normalt ikke direkte, men er i stedet afhængige af de værdier, der er angivet i .env-filen (miljø) i appens rod.
• database/: Indeholder databasefilerne, inklusive migrationer, seeds og testfactories.
• offentlig/: Offentligt tilgængelig mappe, der indeholder kompilerede aktiver og selvfølgelig en index.php-fil.
• ressourcer/: Indeholder frontend-aktiver såsom JavaScriptfiler, sprogfiler, CSS/SASS-filer og alle skabeloner, der bruges i applikationen (kaldet bladeskabeloner).
• ruter/: Alle ruter i applikationen findes her. Der er et par forskellige "omfangsområder" 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 artisan-kommando (for at spare os selv 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 applikationen.

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. vis de tidligere uploadede filer på en anden side.

I dette projekt vil vores applikation være skrivebeskyttet, hvilket betyder, at brugeren kun kan skrive filer og se listen over filer, de har uploadet. Denne applikation er ekstremt grundlæggende, men bør tjene som god praksis for dig til at begynde at opbygge dine Laravel-færdigheder og -viden. Bemærk, at vi for kortheds skyld har udeladt databasemodellering, migreringer og godkendelse, men i en virkelig applikation er disse yderligere ting, du bør overveje.

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

• A rute der vil tillade omverdenen (internettet) at bruge applikationen, samt angive det slutpunkt, der peger på, hvor logikken til at gemme den uploadede fil er placeret.
• A controller der håndterer anmodning-til-svar-flowet.
• A skabelon der 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 sendes fra webformularen.

Hvad er en rute?

En rute i Laravel er dybest set et slutpunkt specificeret af en URI, der fungerer som en "pointer" til en funktionalitet, der tilbydes af applikationen. 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 en controllermetode; den kan også blot sende udførelsen af ​​applikationen til en defineret Closure eller anonym funktion.

Hvorfor bruge en 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 offentligt vendte "browser"-baserede ruter. Disse er de mest almindelige, og det er dem, der rammes af webbrowseren. De kører gennem web middleware-gruppen og indeholder også faciliteter til CSRF-beskyttelse (hvilket hjælper med at forsvare mod formularbaserede ondsindede angreb) og indeholder generelt en grad af "tilstand" (med dette mener vi, at de bruger sessioner).
• api.php: ruter, der svarer til en API-gruppe og dermed har API-middleware aktiveret som standard. Disse ruter er statsløse og har ingen sessioner eller hukommelse til krydsforespørgsler (én anmodning deler ikke data eller hukommelse med nogen anden anmodning; hver enkelt er selvindkapslet).
• console.php: Disse ruter svarer til brugerdefinerede artisan-kommandoer, som du har oprettet til din app.
• channels.php: registrerer ruter til udsendelse af begivenheder.

Den vigtigste fil, man skal være opmærksom på på nuværende tidspunkt, er den browserspecifikke, web.php. Der er allerede defineret én rute som standard, hvilket er den du trykker på, når du navigerer til web-roden af ​​din applikation (web-roden 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.
• /process: Det er her, formularen, der findes i /upload URI'en, sender sine formularindsendte data (formularens "handling").
• /liste: Dette vil liste alle filer, der er uploadet til webstedet.

Bemærk: Slutpunktet /list er muligvis ikke nødvendigt, hvis vi ønsker at samle al logikken til at vise uploadformularen og fillisten på en enkelt side. Vi har dog holdt dem adskilt for nu for at tilføje lidt mere indhold 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 framework-tutorial vil vi for hver ønsket rute eksplicit liste den 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, se denne ud. Disse metoder specificerer, hvilke HTTP-verber der har adgang til den givne rute. Hvis du har brug for, at en rute kan 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 data efter indsendte formularer), kan du bruge metoden Route::any().

Det andet argument til både Route::get()- og Route::post()-metoderne (og alle andre HTTP-verb-relaterede metoder på Route-facaden) er navnet på en specifik controller og den metode, der er placeret i den controller, og som udføres, når den rammer rutens slutpunkt med den tilladte HTTP-anmodning (GET, POST, PATCH osv.). Vi bruger UploadController til alle 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 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, process og list). Det virker måske ikke som en særlig god funktion at give hver rute sit eget navn, når URL har præcis det samme navn, 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 profile-admin eller user-config.

En bemærkning om facader:

• Facader giver en "statisk" grænseflade til klasser, der er tilgængelige i applikationens servicecontainer.
• 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.

I ovenstående rutedefinitioner bruger vi rutefacaden i stedet for manuelt at instansiere et nyt Illuminate/Routing/Router-objekt og kalde de tilsvarende metoder på det objekt. Det er blot en genvej, der sparer penge.pingFacader bruges flittigt i hele Laravel-frameworket; du kan og bør blive mere fortrolig med dem. Dokumentationen til 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 den grundlæggende definition og er også minimumskravet til enhver given controller. Det, den gør mellem disse to ting, betragtes generelt som controllerens "handling" (eller "rutens implementering"). Den fungerer som det andet indgangspunkt til applikationen (den første er anmodningen) for klienten, som sender anmodningsdataen (som vi vender tilbage til næste gang) til applikationen i forventning om en eller anden form for svar (i form af en successide, omdirigering, fejlside eller enhver anden form for HTTP-svar).

En controller gør (grundlæggende) det samme som en rutedefinition med en anonym funktion sat som "handling", når ruten rammes. Forskellen er, at en controller holder sig godt til adskillelsen af ​​bekymringer, mens en rute defineres i tråd med den faktiske rute. URL definition, hvilket grundlæggende betyder, at vi kobler rutens tildelte URI med rutens implementering, eller den kode, der udføres, når den pågældende rute rammes.

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 findes i routes/web.php, men dens implementering findes 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), så se på de fordele, vi får ved at placere vores handlingslogik for den givne "hello-world" rute inde i en controller i stedet for med rutens definition som en callback-funktion:

1. Vores logik er klart opdelt i sin egen klasse (adskillelse af bekymringer).
2. Vores controller er konfigureret til senere udvidelse, hvis vi har brug for at tilføje yderligere funktioner. Lad os sige, at vi ønsker at 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 fylde en rutefil op med hver rutes implementering defineret som callback-funktioner.
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 i applikationen er konfigureret ved hjælp af controllerspecifikke kort.pings (se eksempel nr. 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

Denne kommando genererer i bund og grund en stub til en controller med navnet "UploadController" i hovedcontrollermappen på /app/Http/Controllers/UploadController.php. Du er velkommen til at åbne filen og kigge på den. Den er meget simpel, fordi den kun er en stubbet version af controlleren med den korrekte navneområdesti og de nødvendige klasser, den udvider sig fra.

Generering af anmodningen

Før vi går videre i denne PHP Laravel-tutorial og foretager et par ændringer i UploadControllers genererede stub, vil det give mere mening at oprette request-klassen først. Dette skyldes, at den controller-metode, der håndterer anmodningen, skal type-hinte request-objektet i sin signatur, så den automatisk kan validere de indgående formulardata (som specificeret i rules()-metoden; mere om det senere). Lad os nu bruge artisan-kommandoen igen til at generere vores request stub:

php artisan make:request UploadFileRequest

Denne kommando vil generere en fil kaldet UploadFileRequest i app/Http/Requests/UploadFileRequest. Åbn stubben og tag et kig. Du vil opdage, at den er meget simpel, da den kun indeholder to metoder, authorize() og rules().

Oprettelse af valideringslogikken

Lad os ændre anmodningsstubben, så den imødekommer vores applikations behov. 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 bemærk at authorize()-metoden nu returnerer true i stedet for false. Denne metode afgør, om anmodningen skal tillades at gå ind i applikationen eller ej. Hvis den er sat til false, forhindrer den anmodningen i at komme ind i systemet. Dette ville være et meget praktisk sted at udføre eventuelle autorisationstjek på brugeren eller enhver anden logik, der kan afgøre, om anmodningen kan gå videre til controlleren. For nu returnerer vi bare true her for at tillade alt at bruge anmodningen.

Den anden metode, rules(), er der, 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.I vores uploadapplikation vil der være to felter, der sendes ind via en POST-anmodning fra en formular på frontend'en. Parameteren fileName skal inkluderes i formularens brødtekst (dvs. obligatorisk) og bruges som det filnavn, vi gemmer filen under i lageret (dette gøres i controlleren; vi vender tilbage til det lidt senere). Vi specificerer også, at filnavnet skal være en streng, ved at tilføje et pipe-tegn (|) og ordet 'streng'. Begrænsninger er altid afgrænset af pipes, hvilket giver dig mulighed for at angive yderligere kriterier for det givne felt på en enkelt linje.

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 ville være et billede, ville vi i stedet bruge billedbegrænsningen, hvilket ville begrænse de filtyper, der accepteres som en af ​​de populære billedtyper (jpeg, png, bmp, gif eller svg). Da vi ønsker at give brugeren mulighed for at uploade enhver filtype, holder vi os blot til filvalideringsbegrænsningen.

Det er stort set alt, hvad request-objektet har at byde på. Dets primære opgave er simpelthen at indeholde det acceptable sæt af kriterier (begrænsninger), som formularens parametre skal opfylde for at komme dybere ind i applikationen. En anden ting at bemærke er, at disse to felter (userFile og fileName) også skal specificeres i HTML-koden i form af inputfelter (hvor feltnavnet svarer til navnet i request-objektet).

Du spørger måske: dette definerer, hvad en formularforespørgsel skal indeholde, men hvor udføres den faktiske kontrol af disse begrænsninger? Det vil vi komme ind på i det følgende.

Æ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 process(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'); //so 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 forholdsvis ligetil tilgang til at gemme de uploadede filer på disken. Her er en oversigt over process()-metoden ovenfor:

• Type-hint den request-klasse i controller-metoden, der udfører hovedfunktionaliteten, så vi automatisk kan validere de indgående data.
• Hent filen fra det (nu validerede) request-objekt i controller-metoden.
• Hent 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 bladeskabelonen, som indeholder al HTML, CSS og JavaScript til vores simple applikation. Her er koden; vi vil forklare den senere.

<body>
<h1>Upload a file</h1>
<form id="uploadForm" name="uploadForm" action="{{route('process')}}" 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 at tilføje asynkron funktionalitet (så siden ikke opdateres). Der er en grundlæggende tag uden en method-attribut (som vi vil forklare om et øjeblik) og med en curious action-attribut med værdien {{route('process')}}. I blade er dette det, der kaldes en Direktivet. En direktiv er bare et smart navn for en funktion; det er funktioner, der er specifikke for blade-skabeloner, og som udfører forskellige handlinger, der er fælles for at konstruere websider og webapplikationer. For en bedre forståelse af alle de nyttige ting, som blade kan gøre, kan du se dokumentationen. link.I ovenstående tilfælde bruger vi rutedirektivet til at generere en URL for vores formularindsendelse.

Husk at vi definerede vores ruter tidligere i applikationen i web.php-filen, hvor vi specificerede et navn, der var let at huske, for hver af dem. Direktivet {{route()}} accepterer navnet 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 sine indsendte data til /processen. URL af vores ansøgning, som er defineret som en POST rute.

Det næste, du måske har bemærket, er @csrf-tagget lige under det åbne formulartag. I blade genererer dette tag en _token-parameter på formularen, som kontrolleres i applikationen, før formulardataene må behandles. Dette sikrer, at dataene i formularen er af en gyldig oprindelse, og forhindrer cross-site request forgery-angreb. For mere information om dette, se docs.

Efter dette definerer vi vores formular som normal; bemærk dog, at navnene på vores formularparametre, brugerFile og fileName, er nøjagtig samme som defineret i vores request-objekt. Hvis vi glemte at inkludere input for en given parameter, der var defineret i request-objektet (eller stavede den forkert), ville anmodningen mislykkes, og der ville blive returneret en fejl, hvilket forhindrede den oprindelige formularforespørgsel i nogensinde at ramme controller-metoden, der er placeret i UploadController@process.

Prøv det af, og indsend et par filer til applikationen ved hjælp af denne formular. Gå derefter 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 ser ud lige nu (overordnede detaljer er ikke inkluderet):

Du skal huske, at det request-objekt, vi konstruerede i begyndelsen af ​​denne Laravel-tutorial, skal have de samme parametre defineret i dets rules-metode, som er på formularen i blade-skabelonen (hvis ikke, skal du genlæse afsnittet "Oprettelse af valideringslogikken"). Brugeren indtaster formularen på en webside, der gengives via blade-skabelonmotoren, og sender formularen. Skabelonens jQuery-kode nederst stopper standardindsendelsen (som automatisk omdirigerer til en separat side), opretter en ajax-anmodning, indlæser anmodningen med formulardataene og den uploadede fil og sender det hele til det første lag af vores applikation: anmodningen.

Request-objektet udfyldes ved at associere parametrene i rules()-metoden med de indsendte formularparametre og validerer derefter dataene i henhold til hver specificeret regel. Hvis alle reglerne er opfyldt, sendes anmodningen videre til den controllermetode, der svarer til de værdier, der er defineret i rutefilen web.php. I dette tilfælde er det process()-metoden i UploadController, der udfører arbejdet. Når vi når controlleren, ved vi allerede, at anmodningen har bestået valideringen, så vi behøver ikke at teste igen, om det angivne filnavn faktisk er en streng, eller om userFile-parameteren rent faktisk indeholder en eller anden filtype. Vi kan fortsætte som normalt.

Controller-metoden henter derefter de validerede parametre fra request-objektet, genererer et fuldt filnavn ved at sammenkæde den indsendte fileName-parameter med userFiles originale filtypenavn, gemmer filen i en mappe i vores applikation og returnerer derefter et simpelt JSON-kodet svar, der bekræfter, at anmodningen var vellykket. Svaret modtages af jQuery-logikken, som udfører et par flere brugergrænsefladerelaterede opgaver, såsom at vise succesmeddelelsen (eller fejlmeddelelsen) i 5 sekunder, derefter skjule den, samt rydde de tidligere formularindtastninger. Dette er så brugeren ved med sikkerhed, at anmodningen var vellykket, og kan uploade en anden fil, hvis de ønsker det.

Bemærk også i diagrammet ovenfor, hvor grænsen mellem klienten og serveren går. Dette koncept er absolut afgørende for dig at forstå, og det vil hjælpe dig med at løse problemer og udfordringer, du måtte have i fremtiden, når du f.eks. jonglerer med flere asynkrone anmodninger, der kan opstå på et givet tidspunkt. Adskillelsen er lige ved grænsen af ​​anmodningsobjektet. Selve anmodningsobjektet kan betragtes 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, fortsætter det til controlleren. Alt før det er på frontend ("klienten" betyder bogstaveligt talt "på brugerens computer"). Svaret returneres fra appen tilbage til klientsiden, hvor vores jQuery-kode tålmodigt lytter efter dets ankomst og udfører et par enkle brugergrænsefladeopgaver, når den modtager det.

Vi har også dækket mange 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.

Ofte Stillede Spørgsmål