Tutorial Laravel pentru începători

Ce este Laravel?

Laravel este un cadru web MVC open-source pentru PHP. Laravel este un cadru robust care oferă o dezvoltare ușoară a aplicațiilor web PHP cu caracteristici precum un sistem de ambalare modular cu un manager de dependență dedicat, acces la baze de date relaționale și alte utilități pentru implementarea și întreținerea aplicațiilor.

Laravel a fost creat de Taylor Otwell. De la lansarea sa inițială în iunie 2011 (versiunea 1), a crescut constant în popularitate în sectorul framework-urilor PHP din industria dezvoltării web. O mare parte din această popularitate poate fi atribuită numeroaselor caracteristici axate pe dezvoltatori pe primul loc, pe care le include în mod implicit.

De ce Laravel?

Circa 2000, majoritatea Cod PHP era procedurală și putea fi găsită sub formă de „scripturi” care ar avea o mizerie încurcată de cod spaghete. Chiar și cele mai simple pagini aveau nu separarea preocupărilor...și, prin urmare, era destul de ușor ca o aplicație să se transforme rapid într-un coșmar de mentenanță. Lumea avea nevoie de ceva mai bun. A apărut PHP versiunea 5 și o varietate de framework-uri PHP care încercau să aducă o structură atât de necesară și soluții mai bune pentru diverse probleme ale aplicațiilor web.

De atunci, am văzut numeroase framework-uri lansate care au deschis calea pentru framework-urile populare utilizate astăzi. Astăzi, primele trei ar fi (în opinia noastră) Zend Framework, Symfony și, bineînțeles, Laravel. Deși fiecare dintre aceste framework-uri a fost bazat pe principii similare și este orientat spre rezolvarea (practic) acelorași probleme comune, diferențele lor cheie constau în implementările lor. Fiecare are propriile particularități în ceea ce privește modul de rezolvare a problemelor. Când te uiți la codul produs de fiecare dintre ele, vei vedea că există o linie destul de solidă care le separă unele de altele. În umila noastră opinie, framework-ul Laravel este cel mai bun.

Aflați mai multe despre diferența dintre Laravel și Codeigniter.

Cum să descărcați și să instalați Laravel cu Composer

Notă: Acest tutorial a fost scris pentru Laravel 5.8, dar conceptele de rutare, controler, cerere și Blade rămân aceleași în versiunile actuale. Începând cu 2026, cea mai recentă versiune este Laravel 13 (lansată în martie 2026), care necesită PHP 8.3 sau o versiune ulterioară, în timp ce Laravel 12 necesită PHP 8.2.

Notă: Se presupune că aveți deja o copie de PHP instalată pe sistemul local. Dacă nu, puteți citi cum să o instalați. aici.

Composer este atât un manager de pachete, cât și de dependență. Pentru a-l instala, deschideți un terminal și cd-ul într-un director nou. Rulați această comandă:

curl -Ss getcomposer.org/installer | php

Rezultatele acestei comenzi vor arăta astfel:

Notă: Pentru instrucțiuni mai detaliate despre configurarea Laravel, consultați documentația Laravel aici.

Veți vedea cum descarcă și compilează scriptul composer.phar, pe care îl folosim pentru a instala Laravel. Deși există numeroase modalități de a configura o nouă aplicație Laravel, o vom face prin intermediul scriptului Laravel composer. Pentru a instala acest script, executați:

composer global require laravel/installer

Care va arăta cam așa:

Aceasta operațiune va descărca și instala toate fișierele framework-ului, precum și toate dependențele necesare. Pachetele vor fi salvate în directorul furnizorului. Odată descărcat și instalat, este la fel de simplu ca executarea următoarei comenzi:

laravel new uploadApp

Veți vedea ceva de genul următor rezultat:

Composer instalează toate pachetele de care Laravel are nevoie pentru a rula. Poate dura câteva minute, așa că aveți răbdare. După ce a terminat, rulați comanda ls -al pentru a vedea ce a fost instalat.

Iată o scurtă defalcare a directoarelor dintr-o aplicație comună Laravel:

• aplicație/: Acesta este folderul sursă în care se află codul aplicației noastre. Toate controlerele, politicile și modelele se află în acest folder.
• bootstrap/: Conține scriptul de pornire al aplicației și câteva fișiere de mapare a claselor.
• config/: Conține fișierele de configurare ale aplicației. Acestea nu sunt de obicei modificate direct, ci se bazează pe valorile configurate în fișierul .env (mediu) de la rădăcina aplicației.
• Bază de date/ : Găzduiește fișierele bazei de date, inclusiv migrările, seed-urile și fabricile de testare.
• public/: Dosar accesibil publicului care conține resurse compilate și, bineînțeles, un fișier index.php.
• resurse/: Conține active front-end, cum ar fi JavaFișiere script, fișiere de limbaj, fișiere CSS/SASS și toate șabloanele utilizate în aplicație (numite șabloane blade).
• trasee/ : Toate rutele din aplicație sunt aici. Există câteva „domenii de aplicare” diferite ale rutelor, dar cea pe care ne vom concentra este fișierul web.php.
• depozitare/: Toate fișierele cache temporare utilizate de aplicație, fișierele de sesiune, scripturile de vizualizare compilate și fișierele jurnal.
• teste/: Conține fișiere de testare pentru aplicație, cum ar fi teste unitare și teste funcționale.
• furnizor/: Toate pachetele de dependențe instalate cu composer.

Acum, haideți să construim restul aplicației și să o rulăm cu o comandă specială (pentru a ne scuti de bătaia de cap a instalării și configurării unui server web precum Apache sau nginx). Fișierul .env conține toate valorile de configurare pe care fișierele din directorul /config le folosesc pentru a configura aplicația.

Designul aplicației: o prezentare rapidă a cerințelor noastre

În acest tutorial online Laravel, vom construi o aplicație foarte simplă care va face doar două lucruri:

1. gestionați încărcările de fișiere dintr-un formular web
2. afișa fișierele încărcate anterior pe o pagină diferită.

Pentru acest proiect, aplicația noastră va fi doar de tip write-only, ceea ce înseamnă că utilizatorul poate doar să scrie fișiere și să vizualizeze lista fișierelor pe care le-a încărcat. Această aplicație este extrem de simplă, dar ar trebui să servească drept o bună practică pentru a începe să vă dezvoltați abilitățile și cunoștințele despre Laravel. Rețineți că, de dragul conciziei, am exclus orice modelare a bazelor de date, migrări și autentificare, dar într-o aplicație din lumea reală, acestea sunt lucruri suplimentare pe care va trebui să le luați în considerare.

Iată o listă de componente de care vom avea nevoie pentru ca aplicația să funcționeze conform așteptărilor:

• A traseu care va permite lumii exterioare (internetului) să utilizeze aplicația, precum și va specifica punctul final care va indica locul unde se află logica pentru salvarea fișierului încărcat.
• A controlor care gestionează fluxul de la cerere la răspuns.
• A șablon care va fi folosit pentru a afișa o listă de fișiere încărcate anterior și formularul de încărcare în sine.
• A solicita pe care operatorul le va folosi pentru a valida datele transmise din formularul web.

Ce este un traseu?

O rută în Laravel este practic un punct final specificat de un URI care acționează ca un „pointer” către o funcționalitate oferită de aplicație. Cel mai frecvent, o rută indică pur și simplu o metodă pe un controller și dictează, de asemenea, ce metode HTTP pot accesa acel URI. O rută nu înseamnă întotdeauna o metodă de controller; ar putea pur și simplu să transmită execuția aplicației către o funcție Closure definită sau anonimă.

De ce să folosești o rută?

Rutele sunt stocate în fișierele din folderul /routes din directorul rădăcină al proiectului. În mod implicit, există câteva fișiere diferite care corespund diferitelor „laturi” ale aplicației („laturile” provine din metodologia arhitecturii hexagonale). Acestea includ:

• web.php: rutele bazate pe „browser” orientate spre public. Acestea sunt cele mai comune și sunt cele care sunt accesate de browserul web. Acestea rulează prin grupul middleware web și conțin, de asemenea, facilități pentru Protecție CSRF (care ajută la apărarea împotriva atacurilor rău intenționate bazate pe formulare) și, în general, conțin un anumit grad de „stare” (prin aceasta înțelegem că utilizează sesiuni).
• api.php: rute care corespund unui grup API și, prin urmare, au middleware-ul API activat în mod implicit. Aceste rute sunt fără stare și nu au sesiuni sau memorie pentru cereri încrucișate (o cerere nu partajează date sau memorie cu nicio altă cerere; fiecare este auto-încapsulată).
• console.php: aceste rute corespund comenzilor personalizate artisan pe care le-ați creat pentru aplicația dvs.
• channels.php: înregistrează rute pentru difuzarea evenimentelor.

Fișierul cheie de care trebuie să ne ocupăm în acest moment este cel specific browserului, web.php. Există deja o rută definită implicit, care este cea pe care o accesați direct când navigați la directorul rădăcină web al aplicației dvs. (directorul rădăcină web se află în directorul public). Vom avea nevoie de trei rute diferite pentru ca aplicația noastră de încărcare să funcționeze:

• /upload: acesta va fi URI-ul paginii principale care afișează formularul nostru web pentru încărcarea fișierelor.
• /process: aici va fi locul unde formularul situat la adresa URI /upload își va posta datele trimise prin formular („acțiunea” formularului).
• /list: aceasta va lista toate fișierele încărcate pe site.

Notă: Punctul final /list s-ar putea să nu fie necesar dacă am dori să punem toată logica pentru afișarea formularului de încărcare și a listei de fișiere pe o singură pagină; cu toate acestea, le-am păstrat separat deocamdată pentru a adăuga puțin mai multă substanță subiectului în discuție.

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

În acest tutorial despre framework-ul Laravel, pentru fiecare rută dorită, o vom lista explicit în fișierul de rute web.php folosind una dintre metodele de solicitare specifice HTTP disponibile (get(), post(), put(), delete(), patch() sau options()). Pentru o defalcare a fiecăreia dintre acestea, consultați acest Aceste metode specifică verbele HTTP cărora li se permite să acceseze ruta dată. Dacă aveți nevoie ca o rută să poată accepta mai multe verbe HTTP (ceea ce ar putea fi cazul dacă utilizați o singură pagină pentru a afișa atât datele inițiale, cât și datele formularului post-trimis), puteți utiliza metoda Route::any().

Al doilea argument pentru ambele metode Route::get() și Route::post() (și pentru oricare dintre celelalte metode legate de verbe HTTP de pe fațada Route) este numele unui controller specific și metoda găzduită în interiorul acelui controller care este executată la atingerea punctului final al rutei cu solicitarea HTTP permisă (GET, POST, PATCH etc.). Folosim UploadController pentru toate rutele și le-am specificat în felul următor:

Ultima metodă pe care o apelăm pentru fiecare rută este funcția sa name(), care acceptă un singur șir de caractere ca argument și este utilizată pentru a „eticheta” mai mult sau mai puțin o anumită rută cu un nume ușor de reținut (în cazurile noastre, upload, process și list). S-ar putea să nu pară o caracteristică atât de grozavă să dai fiecărei rute propriul nume atunci când URL se numește exact la fel, dar este foarte util atunci când ai o rută specifică, cum ar fi /users/profile/dashboard/config, care ar fi mai ușor de reținut ca profile-admin sau user-config.

O notă despre fațade:

• Fațadele oferă o interfață „statică” pentru clasele disponibile în containerul de servicii al aplicației.
• Ele oferă o sintaxă concisă, memorabilă, care vă permite să utilizați caracteristicile lui Laravel fără a vă aminti nume lungi de clasă care trebuie injectate sau configurate manual.

În definițiile rutelor de mai sus, folosim fațada Route în loc să instanțiem manual un nou obiect Illuminate/Routing/Router și să apelăm metodele corespunzătoare pe acel obiect. Este doar o scurtătură care economisește timp.pingFațadele sunt utilizate intens în cadrul framework-ului Laravel; puteți și ar trebui să vă familiarizați mai mult cu ele. Documentația pentru Fațade poate fi găsită aici.

Ce este un controler?

Un controler este „C” în arhitectura „MVC” (Model-View-Controller), pe care se bazează Laravel. Munca unui controlor se poate reduce la această definiție simplă: primește cererea de la client și returnează un răspuns clientului. Aceasta este definiția de bază și este, de asemenea, cerința minimă pentru orice controler dat. Ceea ce face între aceste două lucruri este în general considerat „acțiunea” controlerului (sau „implementarea rutei”). Acesta acționează ca al doilea punct de intrare în aplicație (primul fiind cererea) pentru client, care trimite sarcina utilă a cererii (la care vom ajunge în continuare) către aplicație, așteptând un anumit tip de răspuns (sub forma unei pagini de succes, redirecționare, pagină de eroare sau orice alt tip de răspuns HTTP).

Un controler face (practic) același lucru ca o definiție de rută cu o funcție anonimă setată ca „acțiune” atunci când ruta respectivă este accesată. Diferența este că un controler rezistă bine la separarea preocupărilor, în timp ce o rută este definită în linie cu ruta reală. URL definiție, ceea ce înseamnă practic că cuplăm URI-ul atribuit rutei cu implementarea rutei sau cu codul care se execută atunci când este accesată ruta respectivă.

De exemplu, următoarele două bucăți de cod vor realiza același lucru:

Exemplul #1: Definiția și implementarea rutei într-un singur apel de metodă (în fișierul rute web.php)

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

Exemplul #2: Definiția rutei se află în routes/web.php, dar implementarea sa se află în clasa /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);
}
}

Deși exemplul #2 din Laravel pare a necesita mult mai multă muncă (ceea ce nu este, ci doar puțin mai mult cod), uitați-vă la beneficiile pe care le obținem plasând logica noastră de acțiune pentru ruta „hello-world” dată într-un controler, în loc să folosim definiția rutei ca funcție callback:

1. Logica noastră este clar separată în propria sa clasă (separarea preocupărilor).
2. Controlerul nostru este configurat pentru extensii ulterioare, dacă va fi nevoie să adăugăm capabilități suplimentare. Să presupunem că vrem să adăugăm o funcție de tip „la revedere-lume”. În acest caz, am redenumi controlerul într-unul mai generic „HelloController”, apoi am defini două metode separate, Buna ziua() și La revedere(). De asemenea, ar trebui să definim două rute separate care au cartografiat /Buna ziua și / La revedere URI-urile către metoda corespunzătoare de pe controler. Acest lucru este de dorit în comparație cu supraîncărcarea unui fișier de rute cu implementarea fiecărei rute definită ca funcții de apel invers.
3. Laravel are capacitatea încorporată de a stoca în cache toate definițiile rutei din aplicație, astfel încât să accelereze timpul necesar pentru a găsi o anumită rută (mărește performanța aplicației); in orice caz, Vei putea profita de acest lucru doar dacă toate rutele definite în cadrul aplicației sunt configurate folosind o hartă specifică controleruluipings (vezi exemplul nr. 2 de mai sus).

Să rulăm această comandă care va genera un nou controller pentru noi.

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

În esență, această comandă generează un stub pentru un controller numit „UploadController” în directorul principal al controllerului, la adresa /app/Http/Controllers/UploadController.php. Nu ezitați să deschideți fișierul respectiv și să îl consultați. Este foarte simplu, deoarece este doar o versiune extrasă a controllerului, cu calea corectă către spațiul de nume și clasele necesare din care se extinde.

Generarea Cererii

Înainte de a continua în acest tutorial PHP Laravel și de a face câteva modificări la stub-ul generat de UploadController, ar fi mai logic să creăm mai întâi clasa request. Acest lucru se datorează faptului că metoda controller care gestionează cererea trebuie să ofere un tip-hint obiectului request în semnătura sa, permițându-i să valideze automat datele formularului primite (așa cum este specificat în metoda rules(); mai multe despre asta mai târziu). Deocamdată, să folosim din nou comanda artisan pentru a genera stub-ul request-ului nostru:

php artisan make:request UploadFileRequest

Această comandă va genera un fișier numit UploadFileRequest în cadrul aplicației/Http/Requests/UploadFileRequest. Deschideți fișierul și aruncați o privire. Veți găsi că este foarte simplu, conținând doar două metode, authorize() și rules().

Crearea logicii de validare

Să modificăm fișierul request-ului pentru a satisface nevoile aplicației noastre. Modificați fișierul astfel încât să arate astfel:

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

Nu prea multe schimbări, dar observați că metoda authorize() returnează acum true în loc de false. Această metodă decide dacă permite sau nu accesul cererii în aplicație. Dacă este setată la false, oprește intrarea cererii în sistem. Acesta ar fi un loc foarte util pentru a plasa orice verificări de autorizare asupra utilizatorului sau orice altă logică care ar putea decide dacă cererea poate fi transmisă către controller. Deocamdată, returnăm doar true aici pentru a permite oricărui element să utilizeze cererea.

Cealaltă metodă, rules(), este cea în care intervine toată magia validării. Ideea este simplă: returnează un array care conține un set de reguli sub forma:

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

Există multe constrângeri de validare diferite care sunt acceptate de Laravel imediat din cutie. Pentru o listă completă a acestora, consultați documentația online aiciPentru aplicația noastră de încărcare, vor exista două câmpuri care sunt transmise printr-o cerere POST de la un formular din front-end. Parametrul fileName trebuie inclus în corpul formularului (adică obligatoriu) și este utilizat ca nume de fișier sub care vom stoca fișierul în spațiul de stocare (acest lucru se face în controler; vom ajunge la asta puțin mai târziu). De asemenea, specificăm că numele fișierului trebuie să fie un șir de caractere adăugând un caracter vertical (|) și cuvântul „șir de caractere”. Constrângerile sunt întotdeauna delimitate de bare verticale, permițându-vă să specificați orice criterii suplimentare pentru câmpul dat într-o singură linie.

Al doilea parametru, userFile, este fișierul pe care utilizatorul îl încarcă dintr-un formular de pe o pagină web. userFile este, de asemenea, obligatoriu și trebuie să: fi un dosar. Notă: Dacă ne-am aștepta ca fișierul încărcat să fie o imagine, atunci am folosi în schimb constrângerea de tip „imagine”, ceea ce ar limita tipurile de fișiere acceptate la unul dintre tipurile de imagine populare (jpeg, png, bmp, gif sau svg). Deoarece dorim să permitem utilizatorului să încarce orice tip de fișier, vom rămâne la constrângerea de validare a fișierelor.

Cam asta e tot ce înseamnă obiectul request. Rolul său principal este pur și simplu de a conține setul acceptabil de criterii (constrângeri) pe care parametrii corpului formularului trebuie să le îndeplinească pentru a putea avansa în aplicație. Un alt lucru de reținut este că aceste două câmpuri (userFile și fileName) trebuie specificate și în codul HTML sub formă de câmpuri de intrare (cu numele câmpului corespunzător numelui din interiorul obiectului request).

V-ați putea întreba: aceasta definește caracteristicile a ceea ce ar trebui să conțină o cerere de formular, dar unde se face verificarea efectivă a acestor constrângeri? Vom reveni asupra acestui aspect în continuare.

Modificarea Controllerului

Deschideți aplicația/Http/Controllers/UploadController și efectuați următoarele modificări:

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

Deci, este o abordare destul de simplă pentru salvarea fișierelor încărcate pe disc. Iată o descriere detaliată a metodei process() de mai sus:

• Indică clasa de solicitare din metoda controlerului care îndeplinește funcționalitatea principală, astfel încât să putem valida automat datele primite.
• Extrageți fișierul din obiectul request (acum validat) din cadrul metodei controller.
• Extrageți numele fișierului din cerere.
• Generați numele final al fișierului care va fi folosit pentru a salva fișierul sub. Metoda getClientOriginalExtension() pur și simplu preia extensia originală a fișierului încărcat.
• Stocați fișierul în sistemul de fișiere local folosind metoda sa storeAs(), trecând calea numită în directorul /storage ca prim argument și numele fișierului sub care să-l salveze ca al doilea.
• Returnează un răspuns JSON care indică faptul că solicitarea a avut succes.

Șablonul Lamei

Ultima piesă majoră a acestui puzzle este șablonul blade, care va conține toate HTML, CSS și JavaScript pentru aplicația noastră simplă. Iată codul; îl vom explica mai târziu.

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

Iată ce este al nostru /încărcare pagina arata asa:

Acesta este un exemplu foarte tipic de fișier blade care conține un formular HTML și JavaScript/jQuery pentru adăugarea de funcționalități asincrone (astfel încât pagina să nu se reîmprospăteze). Există o funcție de bază etichetă fără atribut de metodă (pe care îl vom explica imediat) și cu un atribut de acțiune curios cu valoarea {{route('process')}}. În blade, aceasta este ceea ce se numește a directivă. O directivă este doar un nume elegant pentru o funcție; acestea sunt funcții specifice șabloanelor blade care efectuează diferite operațiuni comune construirii paginilor web și a aplicațiilor web. Pentru o mai bună înțelegere a tuturor lucrurilor utile pe care le poate face blade, consultați documentația. aiciÎn cazul de mai sus, folosim directiva route pentru a genera o URL pentru trimiterea formularului nostru.

Rețineți că am definit rutele noastre anterior în aplicație, în fișierul web.php, specificând un nume ușor de reținut pentru fiecare dintre ele. Directiva {{route()}} acceptă numele unei rute, o caută în lista de rute memorată intern și generează o rută completă. URL pe baza definiției acelei rute din fișierul web.php. Pentru acest prim caz, specificăm că dorim ca formularul să trimită datele trimise către /proces URL din aplicația noastră, care este definită ca o POST ruta.

Următorul lucru pe care probabil l-ați observat este eticheta @csrf chiar sub eticheta de deschidere a formularului. În Blade, această etichetă generează un parametru _token pe formular, care este verificat în cadrul aplicației înainte ca datele formularului să fie procesate. Acest lucru asigură că datele din formular au o origine validă și previne atacurile de falsificare a cererilor între site-uri. Pentru mai multe informații despre acest subiect, consultați docs.

După aceasta, definim formularul nostru ca fiind normal; totuși, rețineți că numele parametrilor formularului nostru, userFile și fileName, sunt exact aceeași așa cum este definit în obiectul nostru de solicitare. Dacă am uita să includem o intrare pentru un anumit parametru care a fost definit în obiectul de solicitare (sau l-am scris greșit), solicitarea ar eșua și ar fi returnată o eroare, împiedicând cererea originală din formular să acceseze metoda controller situată la UploadController@process.

Încearcă și trimite câteva fișiere către aplicație folosind acest formular. După aceea, navighează la /listă pentru a vedea conținutul folderului de încărcare, cu fișierele pe care le-ați încărcat listate într-un tabel:

Cu cât mai mare Imagine

Să facem un pas înapoi și să vedem ce am făcut în acest tutorial Laravel.

Această diagramă prezintă aplicația așa cum este în prezent (excluzând detaliile de nivel înalt):

Trebuie să rețineți că obiectul request pe care l-am construit la începutul acestui tutorial Laravel ar trebui să aibă aceiași parametri definiți în metoda sa rules ca și în formularul din șablonul blade (dacă nu, recitiți secțiunea „Crearea logicii de validare”). Utilizatorul introduce formularul pe o pagină web care este redată prin intermediul motorului de șabloane blade și trimite formularul. Codul jQuery al șablonului din partea de jos oprește trimiterea implicită (care ar redirecționa automat către o pagină separată), creează o cerere ajax, încarcă cererea cu datele formularului și fișierul încărcat și trimite totul în primul strat al aplicației noastre: cererea.

Obiectul request este populat prin asocierea parametrilor din cadrul metodei rules() cu parametrii formularului trimis, apoi validează datele conform fiecărei reguli specificate. Dacă toate regulile sunt îndeplinite, request-ul este transmis către orice metodă de controller care corespunde valorilor definite în fișierul de rută web.php. În acest caz, metoda process() a UploadController face treaba. Odată ce accesăm controllerul, știm deja că request-ul a trecut validarea, deci nu trebuie să testăm din nou dacă numele fișierului dat este, de fapt, un șir de caractere sau dacă parametrul userFile conține de fapt un anumit tip de fișier. Putem continua normal.

Metoda controller preia apoi parametrii validați din obiectul request, generează un nume de fișier complet prin concatenarea parametrului fileName transmis cu extensia originală a userFile, stochează fișierul într-un director din aplicația noastră, apoi returnează un răspuns simplu, codificat în JSON, care verifică dacă solicitarea a avut succes. Răspunsul este primit de logica jQuery, care îndeplinește câteva sarcini suplimentare legate de interfața utilizator, cum ar fi afișarea mesajului de succes (sau eroare) timp de 5 secunde, apoi ascunderea acestuia, precum și ștergerea intrărilor anterioare din formular. Acest lucru permite utilizatorului să știe sigur că solicitarea a avut succes și poate încărca un alt fișier, dacă dorește.

De asemenea, rețineți în diagrama de mai sus unde este trasată linia de demarcație între client și server. Este absolut esențial să înțelegeți acest concept și vă va ajuta să rezolvați problemele și dificultățile pe care le puteți întâmpina în viitor atunci când jongleați, de exemplu, cu mai multe cereri asincrone care pot apărea în orice moment. Separarea se află chiar la limita obiectului cererii. Obiectul cererii în sine poate fi considerat „poarta de acces” către restul aplicației. Acesta efectuează validarea inițială și înregistrarea valorilor formularului transmise de browserul web. Dacă acestea sunt considerate valide, atunci continuă către controler. Tot ce se află înainte de aceasta se află în front-end („clientul” înseamnă literalmente „pe computerul utilizatorului”). Răspunsul este returnat de aplicație înapoi în partea de client, unde codul nostru jQuery ascultă cu răbdare sosirea acestuia și efectuează câteva sarcini simple de interfață cu utilizatorul odată ce îl primește.

De asemenea, am acoperit multe întrebări importante adresate frecvent Întrebări de interviu legate de Laravel și PHP pentru studenții, precum și pentru candidații cu experiență, pentru a obține postul potrivit.

Întrebări frecvente