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 devenit din ce în ce mai popular în sectorul PHP-framework al industriei dezvoltării web. O mare parte din această popularitate poate fi atribuită numeroaselor funcții care au în vedere primul dezvoltator pe care le oferă stoc.

De ce Laravel?

Circa 2000, majoritatea coduri 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 astfel a fost destul de ușor pentru o aplicație să devină rapid un coșmar de întreținere. Lumea avea nevoie de ceva mai bun... Introduceți versiunea PHP 5 și o varietate de framework-uri PHP care încearcă să aducă o rezoluție atât de necesară și soluții mai bune pentru diverse probleme legate de aplicațiile web.

De atunci, am văzut multe cadre lansate care ar deschide calea pentru cadrele populare existente și folosite astăzi. Astăzi, primii trei ar fi (în opinia noastră) Zend Framework, Symfony și bineînțeles Laravel. Deși fiecare dintre aceste cadre a fost fondată pe principii similare și sunt orientate spre rezolvarea (practic) aceleași probleme comune, diferențele lor cheie constă în implementările lor. Fiecare are propriile sale ciudații despre cum să rezolve problemele. Când te uiți la codul produs de fiecare dintre ei, vei vedea că există o linie destul de solidă care îi separă unul de celălalt. În opinia noastră umilă, 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Ă Se presupune că aveți deja o copie a PHP instalată pe sistemul dumneavoastră local. Dacă nu, puteți citi cum să-l 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:

notițe Pentru instrucțiuni mai detaliate despre configurarea Laravel, consultați documentația Laravel aici.

Îl veți vedea descarcând și compilând scriptul composer.phar, care este ceea ce 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 de compoziție Laravel. Pentru a instala acest script, rulați:

composer global require laravel/installer

Care va arăta cam așa:

Acest lucru va descărca și instala toate fișierele cadru în sine, precum și toate dependențele necesare. Pachetele vor fi salvate în directorul furnizorului. Odată descărcat și instalat, este la fel de ușor ca lansarea 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 este terminat, rulați o comandă ls -al pentru a arunca o privire la ceea 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 hărți de clasă
config/: Deț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, semințele și fabricile de testare
public/: Dosar accesibil public care conține active compilate și, desigur, un fișier index.php
resurse/: Conține elemente front-end, cum ar fi fișiere javascript, fișiere de limbă, 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 „sfere” diferite de rute, dar cel 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ță instalate cu composer

Acum, haideți să construim restul aplicației și să o rulăm cu o comandă specială artizanală (pentru a ne economisi bătălia de a instala și configura un 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. În interiorul acestuia, veți observa că valoarea de configurare pentru diverși parametri utilizați de interiorul aplicației.

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:

gestionați încărcările de fișiere dintr-un formular web
afișarea fișierelor încărcate anterior pe o altă pagină.

Pentru acest proiect, aplicația noastră va fi doar pentru scriere, ceea ce înseamnă că utilizatorul poate scrie doar fișiere și poate vizualiza lista fișierelor pe care le-a încărcat. Această aplicație este extrem de simplă, dar ar trebui să servească drept bună practică pentru a începe să vă dezvoltați abilitățile și cunoștințele Laravel. Rețineți că, din motive de concizie, am exclus orice modelare a bazei de date, migrare și autentificare, dar, într-o aplicație din lumea reală, acestea sunt lucruri suplimentare pe care veți dori 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 (internet) să folosească aplicația, precum și să specifice punctul final care va indica unde se află logica pentru salvarea fișierului încărcat
A controlor care gestionează fluxul de solicitare 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 propriu-zis
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 „indicator” către o anumită funcționalitate oferită de aplicație. Cel mai frecvent, o rută indică pur și simplu o metodă de pe un controler și, de asemenea, dictează ce metode HTTP pot atinge acel URI. Nici o rută nu înseamnă întotdeauna metoda controlerului; ar putea trece pur și simplu execuția aplicației unei funcții de închidere sau anonime definite.

De ce să folosiți Route?

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” care se confruntă cu publicul. Acestea sunt cele mai comune și este ceea ce este lovit de browserul web. Acestea rulează prin grupul de middleware web și, de asemenea, conțin facilități pentru protectie csrf (care ajută la apărarea împotriva atacurilor și hackurilor rău intenționate bazate pe formulare) și, în general, conțin un anumit grad de „stare” (prin aceasta mă refer că folosesc sesiuni)
api.php Rute care corespund unui grup de API și, astfel, au activat în mod implicit middleware-ul API. Aceste rute sunt apatride și nu au sesiuni sau memorie de cereri încrucișate (o cerere nu partajează date sau memorie cu nicio altă solicitare – fiecare este auto-încapsulată).
console.php Aceste rute corespund comenzilor artizanale personalizate pe care le-ați creat pentru aplicația dvs
channels.php Înregistrează rutele pentru difuzarea evenimentelor

Fișierul cheie de care trebuie să vă ocupați în acest moment este cel specific browserului, web.php . Există deja o rută definită implicit, care este cea pe care o atingeți chiar când navigați la rădăcina web a aplicației dvs. (rădăcina 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 Acesta va fi locul în care formularul situat la URI /upload își postează datele trimise prin formular („acțiunea” formularului)
/list Aceasta va lista toate fișierele încărcate pe site

nota Este posibil ca punctul final /list să nu fie necesar dacă dorim să punem toată logica pentru afișarea formularului de încărcare și a listei de fișiere pe o singură pagină, totuși, le-am păstrat separate pentru moment pentru a adăuga puțin mai mult subiectului în cauză. .

//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 de framework Laravel, pentru fiecare rută dorită, o vom enumera în mod explicit în fișierul de rute web.php folosind una dintre metodele de solicitare specifice HTTP disponibile (get(), post(), put() , delete(), patch() sau opțiuni()). Pentru o defalcare a fiecăreia dintre acestea, verificați acest afară. Ceea ce fac aceste metode este să specifice care verbe HTTP au voie să acceseze acea rută dată. Dacă aveți nevoie de o rută pentru a putea accepta mai mult de un verb HTTP (ceea ce ar putea fi cazul dacă utilizați o singură pagină atât pentru a afișa datele inițiale, cât și pentru a posta datele formularului trimis), puteți utiliza Route::any( ) metoda.

Al doilea argument pentru ambele metode Route::get() și Route::post() (și oricare dintre celelalte metode legate de verbe HTTP de pe fațada Route), este numele unui Controller și al unei metode specifice găzduite în interiorul acestuia. controlerul care este executat la atingerea punctului final al rutei cu cererea HTTP permisă (GET, POST, PATCH etc.) Utilizăm UploadController pentru toate cele trei rute și le-am specificat în felul următor:

Ultima metodă pe care o apelăm pe fiecare rută este funcția sa name(), care acceptă un singur șir ca argument și este folosită pentru a „eticheta” mai mult sau mai puțin o anumită rută cu un nume ușor de reținut (în cazurile noastre, încărcare, procesare și listă). Îmi dau seama că nu pare atât de mare o caracteristică de a da fiecărei rute propriul nume atunci când URL-ul este numit exact la fel, dar este într-adevăr util atunci când aveți o anumită rută, 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 care sunt 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.

Definițiile rutei de mai sus din acest tutorial cadru Laravel, 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 comandă rapidă care economisește tastarea. Fațadele sunt utilizate intens în cadrul Laravel – puteți și ar trebui să vă familiarizați mai bine cu ele. Documentele pentru Fațade pot fi găsite 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 generală și este, de asemenea, cerințele minime ale oricărui controler dat. Ceea ce face între cele două lucruri este în general considerat „acțiunea” controlorului (sau „implementarea rutei”). Acesta acționează ca al doilea punct de intrare în aplicație (primul fiind cererea) către 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 unui pagină 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 acea rută este lovită. Diferența este că un controler rezistă bine la separarea preocupărilor în timp ce o rută este definită în linie cu definiția URL reală, ceea ce înseamnă practic că cuplăm URI-ul atribuit rutei cu implementarea rutei sau codul care se execută atunci când acea rută este lovit.

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 este în interiorul routes/web.php, dar implementarea sa rezidă î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 fi mult mai mult de lucru (ceea ce nu este, doar puțin mai mult cod este tot), uită-te la beneficiile pe care le obținem punând în schimb logica noastră de acțiune pentru traseul „hello-world” dat în interiorul unui controler. cu definiția rutei ca funcție de apel invers:

Logica noastră este clar separată în propria sa clasă (separarea preocupărilor)
Controlerul nostru este configurat pentru extensie mai târziu dacă trebuie să îi adăugăm capabilități suplimentare... Să spunem că poate am vrut să adăugăm o caracteristică „adio-lumea”... În acest caz, am redenumi controlerul într-un „HelloController” mai generic, apoi definim două metode separate, Buna ziua() si La revedere(). De asemenea, ar trebui să definim două rute separate care au cartografiat /Buna ziua si / La revedere URI-urile la metoda lor adecvată pe controler. Acest lucru este de dorit în comparație cu îngrășarea unui fișier de rute cu implementarea fiecărei rute definite ca funcții de apel invers.
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, veți putea profita de asta numai dacă toate rutele definite din interiorul aplicației sunt configurate folosind mapări specifice controlerului (vezi Exemplul #2 de mai sus)

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

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

În esență, ceea ce face această comandă este generează un stub pentru un controler numit „UploadController” în directorul principal al controlerului la /app/Http/Controllers/UploadController.php. Nu ezitați să deschideți acel fișier și să aruncați o privire. Este foarte simplu, deoarece este doar o versiune a controlerului, cu calea corectă a spațiului de nume și clasele necesare de la care se extinde.

Generarea Cererii

Înainte de a merge mai departe în acest tutorial PHP Laravel și de a face câteva modificări la stub-ul generat de UploadController, cred că va avea mai mult sens să creăm mai întâi clasa de solicitare. Acest lucru se datorează faptului că metoda controlerului care gestionează cererea trebuie să tastați hint obiectul cererii în semnătura sa, permițându-i să valideze automat datele din formularul de intrare (așa cum este specificat în metoda regulilor(). Mai multe despre asta mai târziu...) Deocamdată, să folosim comanda artizanală din nou pentru a genera stutul de solicitare:

php artisan make:request UploadFileRequest

Această comandă va genera un fișier numit UploadFileRequest în interiorul app/Http/Requests/UploadFileRequest. Deschideți stub-ul și aruncați o privire... Veți găsi că este foarte simplu, care conține doar două metode, authorize() și reguli.

Crearea logicii de validare

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

<?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 sunt multe modificări, dar observați că metoda authorize() returnează acum true în loc de false. Această metodă decide dacă permite sau nu intrarea cererii în aplicație. Dacă este setat la fals, oprește intrarea cererii în sistem (care ar fi în mod normal o metodă pe controler). Acesta ar fi un loc foarte la îndemână pentru a pune orice verificări de autorizare asupra utilizatorului sau orice altă logică care poate decide dacă cererea poate fi transmisă controlorului. Deocamdată, ne întoarcem aici pentru a permite orice și orice să folosească cererea.

Cealaltă metodă, regulile () este locul în care toată magia intră în joc în ceea ce privește validarea. Ideea este simplă: returnează o matrice 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 aici. Pentru aplicația noastră de încărcare, vor fi două câmpuri care vor fi transmise prin solicitare POST dintr-un formular de pe front-end. Parametrul fileName trebuie inclus în corpul formularului (adică obligatoriu) și este folosit ca nume de fișier în care vom stoca fișierul în stocare (acest lucru se face în controler – vom ajunge la el puțin mai târziu). De asemenea, precizăm că numele fișierului trebuie să fie un șir prin adăugarea unui caracter pipe (|) și a cuvântului „șir”. Constrângerile sunt întotdeauna delimitate de conducte, permițându-vă să specificați orice criterii suplimentare pentru câmpul dat într-o singură linie! Ce putere!

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

Cam asta este tot ceea ce are obiectul de cerere. Sarcina sa principală este să mențină pur și simplu setul acceptabil de criterii (constrângeri) pe care trebuie să le îndeplinească parametrii corpului formularului pentru a continua mai profund în aplicație. Un alt lucru de remarcat este că aceste două câmpuri (userFile și filename) trebuie specificate și în interiorul codului HTML sub formă de câmpuri de intrare (cu numele câmpului corespunzător numelui din interiorul obiectului de solicitare).

S-ar putea să vă întrebați: sigur că acest lucru definește caracteristicile a ceea ce ar trebui să conțină o cerere de formular, dar unde se face verificarea reală a acestor constrângeri? Vom intra în asta î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 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
   }
}

Deci, este o abordare destul de simplă pentru a salva fișierele încărcate pe disc. Iată o detaliere a metodei upload() de mai sus:

Tastați clasa de solicitare în metoda controlerului care face funcționalitatea „carne și cartofi”, astfel încât să putem valida automat datele primite
Luați fișierul din obiectul de cerere (acum validat) din cadrul metodei controlerului (în acest caz l-am numit upload() dar ar fi putut fi numit și cu un nume mai standardizat, cum ar fi store()).
Luaț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.
Întoarceți 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 tot 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('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>

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 (deci pagina nu se reîmprospătează). Există o bază etichetă fără atribut de metodă (pe care o voi explica în doar o secundă) și cu un atribut de acțiune curios cu valoarea {{route('file.upload')}}. În blade, acesta este ceea ce este cunoscut sub numele de a directivă. O directivă este doar un nume de lux pentru funcție – sunt funcții specifice șabloanelor blade care efectuează diferite operațiuni care sunt comune pentru construirea de pagini web și aplicații web. Pentru o mai bună înțelegere a tuturor lucrurilor interesante pe care blade le poate face, consultați documentele aici. În cazul de mai sus, folosim directiva rută pentru a genera o adresă URL pentru trimiterea formularului nostru.

Amintiți-vă că ne-am definit rutele mai devreme în aplicație în interiorul fișierului web.php, specificând un nume ușor de reținut pentru fiecare dintre ele. Directiva {{route()}} acceptă un nume al unei rute, îl caută în lista de rute din cacheul intern și generează o adresă URL completă pe baza definiției acelei rute în fișierul web.php. Pentru acest prim caz, precizăm că dorim ca formularul să trimită datele trimise către adresa URL /process a aplicației noastre, care este definită ca un POST ruta.

Următorul lucru ciudat pe care poate l-ați observat este eticheta @csrf chiar sub eticheta formularului de deschidere. În blade, această etichetă generează un parametru _token pe formular, care este verificat în interiorul aplicației înainte ca datele din formular să fie permise să fie procesate. Acest lucru asigură faptul că datele din formular sunt de origine validă și previne atacurile între site-uri, cereri de falsificare. Pentru mai multe informații despre aceasta, 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 cererii noastre. Dacă am uitat să includem o intrare pentru un parametru dat care a fost definit în obiectul de solicitare (sau l-am scris greșit), cererea ar eșua și va fi returnată o eroare, împiedicând solicitarea formularului original să lovească vreodată metoda controlerului situată la UploadController@ proces .

Încercați-l și trimiteți câteva fișiere în aplicație folosind acest formular. După aceea, navigați 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ă ilustrează aplicația așa cum este acum (excluse detaliile de nivel înalt):

Ar trebui să vă amintiți că obiectul de solicitare pe care l-am construit la începutul acestui tutorial Laravel ar trebui să aibă aceiași parametri definiți în metoda regulilor sale ca și pe formularul din șablonul blade (dacă nu recitiți secțiunea „Crearea logicii de validare”). . Utilizatorul introduce formularul într-o pagină web care este redată printr-un motor de șablon blade (acest proces este desigur pe pilot automat, așa că nici nu trebuie să ne gândim la asta) ș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 solicitare ajax, încarcă cererea cu datele din formular și a încărcat fișierul și trimite totul în primul strat al nostru. cerere: cererea.

Obiectul de solicitare 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, cererea este transmisă la orice metodă de control care corespunde valorilor definite în fișierul de rută web.php. În acest caz, metoda process() a UploadController este cea care face treaba. Odată ce atingem controlerul, știm deja că cererea a trecut validarea, așa că nu trebuie să testăm din nou dacă numele fișierului dat este, de fapt, un șir sau parametrul userFile deține de fapt un tip de fișier... Putem continua ca normal.

Metoda controlerului preia apoi parametrii validați din obiectul de solicitare, generează un nume complet de fișier prin concatenarea parametrului fileName transmis cu extensia originală a userFile, stochează fișierul într-un director din aplicația noastră, apoi returnează un simplu cod JSON. răspuns prin care se verifică dacă cererea a avut succes. Răspunsul este primit de logica jQuery, care face mai multe sarcini legate de interfața de utilizare, 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... asta pentru ca utilizatorul să știe cu siguranță că solicitarea a avut succes și că pot încărca un alt fișier, dacă doresc.

De asemenea, rețineți în diagrama de mai sus exact locul în care este trasată linia între client și server. Acest concept este absolut esențial pentru ca dvs. să înțelegeți și vă va ajuta să rezolvați problemele și problemele pe care le puteți avea în viitor atunci când jonglați, de exemplu, cu mai multe solicitări asincrone care pot apărea la un moment dat. Separarea este chiar la limita obiectului de cerere. Obiectul de solicitare în sine poate fi considerat „poarta de acces” către restul aplicației... Acesta efectuează validarea și înregistrarea inițială a valorilor formularului transmise din browserul web. Dacă sunt considerate valide, atunci se continuă controlorului. Totul înainte de asta se află pe front-end („clientul” înseamnă literal „pe computerul utilizatorului”). Răspunsul este returnat din aplicație înapoi în partea clientului, unde codul nostru jQuery ascultă cu răbdare sosirea lui și face câteva sarcini simple de UI odată ce îl primește.

Am acoperit aproape 90+ de întrebări importante frecvente Î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.

S-ar putea sa-ti placa: