Laravel-opplæring for nybegynnere

Laravel ble skapt av Taylor Otwell. Siden den første utgivelsen i juni 2011 (versjon 1), har den stadig vokst mer og mer populær i PHP-rammesektoren i webutviklingsindustrien. Mye av denne populariteten kan tilskrives de mange utviklervennlige funksjonene som følger med på lager.

Hvorfor Laravel?

Cirka 2000, de fleste PHP-koder var prosedyremessig og kunne bli funnet i form av "manus" som ville ha et sammenfiltret rot av spaghettikode. Selv de enkleste sidene hadde nei separasjon av bekymringer, og dermed var det ganske enkelt for en applikasjon å raskt vokse til et vedlikeholdsmareritt. Verden trengte noe bedre ... Gå inn i PHP versjon 5 og en rekke PHP-rammeverk for å prøve å bringe noen sårt tiltrengte løsninger og bedre løsninger på ulike webapplikasjonsproblemer.

Siden den gang har vi sett mange rammeverk utgitt som ville bane vei for de populære rammeverkene som eksisterer og brukes i dag. I dag ville topp tre (etter vår mening) vært Zend Framework, Symfony og selvfølgelig Laravel. Selv om hvert av disse rammeverkene ble grunnlagt på lignende prinsipper og er rettet mot å løse (i utgangspunktet) de samme vanlige problemene, er nøkkelforskjellene deres implementeringen. De har hver sine særheter om hvordan de skal gå frem for å løse problemer. Når du ser på koden produsert av hver av dem, vil du se at det er en ganske solid linje som skiller dem fra hverandre. Etter vår ydmyke mening er Laravel-rammeverket det beste.

Lær mer om Forskjellen mellom Laravel og CodeIgniter

Hvordan laste ned og installere Laravel med Composer

MERKNADER Det antas at du allerede har en kopi av PHP installert på ditt lokale system. Hvis ikke, kan du lese hvordan du installerer det her.

Composer er både en pakke- og avhengighetsbehandler. For å installere det, åpne en terminal og cd inn i en ny katalog. Kjør denne kommandoen:

curl -Ss getcomposer.org/installer | php

Resultatene av denne kommandoen vil se slik ut:

Merknader For mer omfattende instruksjoner om oppsett av Laravel, se Laravel-dokumentasjonen her..

Du vil se det laste ned og kompilere composer.phar-skriptet, som er det vi bruker til å installere Laravel. Selv om det er mange måter å sette opp en ny Laravel-applikasjon på, vil vi gjøre det via Laravel-komponistskriptet. For å installere dette skriptet, kjør:

composer global require laravel/installer

Som vil se omtrent slik ut:

Dette vil laste ned og installere alle rammefilene selv, så vel som alle avhengigheter som det krever. Pakkene vil bli lagret i leverandørkatalogen. Når den er lastet ned og installert, er det like enkelt som å gi følgende kommando:

laravel new uploadApp

Du vil se noe sånt som følgende utgang:

Composer installerer alle pakkene som Laravel trenger for å kjøre. Det kan ta noen minutter, så vær tålmodig. Etter at den er ferdig, kjør en ls -al-kommando for å se på hva som ble installert.

Her er en kort oversikt over katalogene i en vanlig Laravel-applikasjon:

• app/ : Dette er kildemappen der applikasjonskoden vår ligger. Alle kontrollere, policyer og modeller er inne i denne mappen
• bootstrap/ : Inneholder programmets oppstartsskript og noen få klassekartfiler
• config/ : Inneholder appens konfigurasjonsfiler. Disse endres vanligvis ikke direkte, men stoler i stedet på verdiene som er satt opp i .env (miljø)-filen i roten av appen
• database/ : Inneholder databasefilene inkludert migreringer, frø og testfabrikker
• offentlig/ : Offentlig tilgjengelig mappe som inneholder kompilerte eiendeler og selvfølgelig en index.php-fil
• ressurser/ : Inneholder front-end-ressurser som javascript-filer, språkfiler, CSS/SASS-filer og alle maler som brukes i applikasjonen (kalt bladmaler)
• ruter/: Alle ruter i applikasjonen er inne her. Det er noen forskjellige "omfang" av ruter, men den vi vil fokusere på er web.php-filen
• lagring/ : Alle midlertidige cache-filer som brukes av applikasjonen, sesjonsfiler, kompilerte visningsskript og loggfiler
• tester/: Inneholder testfiler for applikasjonen som enhetstester og funksjonstester.
• leverandør/: Alle avhengighetspakker installert med composer

La oss nå bygge resten av appen og kjøre den med en spesiell håndverkerkommando (for å spare oss selv for bryet med å installere og konfigurere en webserver som Apache eller nginx). .env-filen inneholder alle konfigurasjonsverdiene som filene i /config-katalogen bruker for å konfigurere programmet. Inne i den vil du legge merke til at konfigurasjonsverdien for ulike parametere brukes av applikasjonens interne deler.

Applikasjonsdesign: En rask gjennomgang av våre krav

I denne online Laravel-opplæringen skal vi bygge en veldig enkel applikasjon som bare vil gjøre to ting:

1. håndtere filopplastinger fra et nettskjema
2. viser de tidligere opplastede filene på en annen side.

For dette prosjektet vil applikasjonen vår være skrivebeskyttet, noe som betyr at brukeren bare kan skrive filer og se listen over filer de har lastet opp. Denne applikasjonen er ekstremt grunnleggende, men bør tjene som god praksis for deg å begynne å bygge Laravel ferdigheter og kunnskaper på. Legg merke til at for korthets skyld har jeg ekskludert databasemodellering, migreringer og autentisering, men i en virkelig applikasjon er dette flere ting du bør vurdere.

Her er en liste over komponenter som vi trenger for å få applikasjonen til å fungere som forventet:

• A rute som vil tillate omverdenen (internett) å bruke applikasjonen, samt spesifisere endepunktet som vil peke til hvor logikken for å lagre den opplastede filen er plassert
• A controller som håndterer forespørselen til svarflyt
• A mal som vil bli brukt til å vise en liste over tidligere opplastede filer og selve opplastingsskjemaet
• A anmode som behandlingsansvarlig vil bruke for å validere dataene som sendes inn fra nettskjemaet

Hva er en rute?

En rute i Laravel er i utgangspunktet et endepunkt spesifisert av en URI som fungerer som en "peker" til en del funksjonalitet som tilbys av applikasjonen. Oftest peker en rute ganske enkelt til en metode på en kontroller og dikterer også hvilke HTTP-metoder som kan treffe den URI. En rute betyr ikke alltid kontrollermetode heller; det kan bare overføre kjøringen av applikasjonen til en definert nedleggelse eller anonym funksjon også.

Hvorfor bruke rute?

Ruter lagres i filer under /routes-mappen i prosjektets rotkatalog. Som standard er det noen få forskjellige filer som tilsvarer de forskjellige "sidene" av applikasjonen ("sider" kommer fra den sekskantede arkitekturmetodikken). De inkluderer:

• web.php De offentlige vendte "nettleser"-baserte rutene. Disse er de vanligste og er det som blir truffet av nettleseren. De går gjennom webmellomvaregruppen og inneholder også fasiliteter for csrf-beskyttelse (som hjelper til med å forsvare seg mot formbaserte ondsinnede angrep og hacks) og generelt inneholder en grad av "tilstand" (med dette mener jeg at de bruker økter)
• api.php Ruter som tilsvarer en API-gruppe og dermed har API-mellomvaren aktivert som standard. Disse rutene er statsløse og har ingen økter eller minne for kryssforespørsel (én forespørsel deler ikke data eller minne med noen annen forespørsel - hver enkelt er selvinnkapslet).
• console.php Disse rutene tilsvarer egendefinerte håndverkskommandoer som du har laget for appen din
• channels.php Registrerer ruter for sending av hendelser

Nøkkelfilen å være opptatt av på dette tidspunktet er den nettleserspesifikke, web.php . Det er allerede én rute definert som standard, som er den du treffer rett når du navigerer til webroten til applikasjonen din (nettroten er i den offentlige katalogen). Vi trenger tre forskjellige ruter for at opplastingsapplikasjonen vår skal fungere:

• /upload Dette vil være URI-en til hovedsiden som viser nettskjemaet vårt for opplasting av filer.
• /prosess Dette vil være der skjemaet som ligger på /upload-URI-en legger ut skjemainnsendte data til (skjemaets "handling")
• /list Dette vil vise alle filer lastet opp til nettstedet

note /list-endepunktet er kanskje ikke nødvendig hvis vi ønsker å legge all logikken for å vise opplastingsskjemaet og listen over filer på en enkelt side, men vi holdt dem atskilt for nå for å legge til litt mer sak 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-rammeveiledningen, for hver ønsket rute, vil vi liste den eksplisitt i rutefilen web.php ved å bruke en av de tilgjengelige HTTP-spesifikke forespørselsmetodene (get(), post(), put() , delete(), patch() eller options() ). For en oversikt over hver av disse, sjekk denne ute. Hva disse metodene gjør er å spesifisere hvilke HTTP-verb som har tilgang til den gitte ruten. Hvis du trenger en rute for å kunne godta mer enn ett HTTP-verb (som kan være tilfellet hvis du bruker en enkelt side for både å vise de første dataene og legge inn innsendte skjemadata), kan du bruke Route::any( ) metode.

Det andre argumentet til både Route::get()- og Route::post()-metoden (og enhver av de andre HTTP-verb-relaterte metodene på rutefasaden), er navnet på en spesifikk kontroller og metode som ligger inne i den kontroller som blir utført ved å treffe rutens endepunkt med den tillatte HTTP-forespørselen (GET, POST, PATCH, etc.) Vi bruker UploadController for alle tre rutene og har spesifisert dem på følgende måte:

Den siste metoden vi kaller på hver rute er dens navn()-funksjon, som aksepterer en enkelt streng som et argument og brukes til mer eller mindre å "merke" en bestemt rute med et navn som er lett å huske (i våre tilfeller, laste opp, behandle og liste). Jeg innser at det ikke virker så bra å gi hver rute sitt eget navn når nettadressen heter nøyaktig det samme, men det kommer virkelig godt med når du har en spesifikk rute som /users/profile/dashboard/config, som ville være lettere å huske som profile-admin eller user-config.

En merknad om fasader:

• Fasader gir et "statisk" grensesnitt til klasser som er tilgjengelige i applikasjonens tjenestebeholder."
• De gir en kortfattet, minneverdig syntaks som lar deg bruke Laravels funksjoner uten å huske lange klassenavn som må injiseres eller konfigureres manuelt.

Rutedefinisjonene ovenfor i denne Laravel-rammeveiledningen bruker vi rutefasaden i stedet for manuelt å instansiere et nytt Illuminate/Routing/Router-objekt og kalle de tilsvarende metodene på det objektet. Det er bare en snarvei som sparer skriving. Fasader brukes mye i Laravel-rammeverket – du kan og bør bli mer kjent med dem. Dokumentene for fasader finner du her..

Hva er en kontroller?

En kontroller er "C" i "MVC" (Model-View-Controller)-arkitekturen, som er det Laravel er basert på. En kontrollers jobb kan kokes ned til denne enkle definisjonen: Den mottar forespørselen fra klienten og returnerer et svar til klienten. Dette er bare-bones-definisjonen og er også minimumskravene til en gitt kontroller. Hva den gjør mellom disse to tingene blir generelt sett på som "handlingen" til kontrolleren (eller "rutens implementering"). Den fungerer som det andre inngangspunktet til applikasjonen (det første er forespørselen) til klienten, som sender forespørselens nyttelast (som vi kommer til neste gang) til applikasjonen, og forventer en form for respons (i form av en suksessside, omdirigering, feilside eller annen type HTTP-respons).

En kontroller gjør (i utgangspunktet) det samme som en rutedefinisjon med en anonym funksjon satt som "handlingen" når den ruten blir truffet. Forskjellen er at en kontroller holder godt med separasjonen av bekymringer mens en rute er definert i tråd med den faktiske url-definisjonen, noe som i bunn og grunn betyr at vi kobler rutens tilordnede URI med rutens implementering, eller koden som kjøres når den ruten er treffer.

For eksempel vil følgende to kodebiter oppnå det samme:

Eksempel #1: Rutens definisjon og implementering i et enkelt metodekall (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 definisjon er innenfor routes/web.php, men implementeringen ligger i /app/Http/Controllers/HelloWorldController-klassen

//inside routes/web.php
<?php

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

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

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

Selv om Laravel-eksempel #2 virker som mye mer arbeid (som det ikke er – bare litt mer kode er alt), se på fordelene vi oppnår ved å plassere handlingslogikken vår for den gitte «hallo-verden»-ruten inne i en kontroller i stedet av med rutens definisjon som en tilbakeringingsfunksjon:

1. Vår logikk er rent atskilt i sin egen klasse (separasjon av bekymringer)
2. Kontrolleren vår er satt opp for utvidelse senere hvis vi trengte å legge til flere funksjoner til den ... Si at vi kanskje ønsket å legge til en "farvel-verden"-funksjon... I dette tilfellet ville vi endre navn på kontrolleren til en mer generisk "HelloController" og deretter definere to separate metoder, hallo() og adjø(). Vi må også definere to separate ruter som kartla /Hallo og / ha det URIer til deres passende metode på kontrolleren. Dette er ønskelig sammenlignet med å fete opp en rutefil med hver rutes implementering definert som tilbakeringingsfunksjoner.
3. Laravel har den innebygde evnen til å cache alle rutedefinisjonene i applikasjonen slik at den øker tiden det tar å finne en gitt rute (øker applikasjonsytelsen); imidlertid, du vil bare kunne dra nytte av det hvis alle dine definerte ruter inne i applikasjonen er konfigurert ved hjelp av kontrollerspesifikke tilordninger (se eksempel #2 ovenfor)

La oss kjøre denne kommandoen som vil generere en ny kontroller for oss.

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

I hovedsak genererer denne kommandoen en stubbe for en kontroller kalt "UploadController" inne i hovedkontrollerkatalogen på /app/Http/Controllers/UploadController.php. Åpne den filen og ta en titt. Det er veldig enkelt fordi det bare er en utstoppet versjon av kontrolleren, med riktig navneområdebane og de nødvendige klassene som den strekker seg fra.

Genererer forespørselen

Før vi går videre i denne PHP Laravel-opplæringen og gjør noen få endringer i UploadControllerens genererte stubb, tror jeg det vil være mer fornuftig å lage forespørselsklassen først. Dette er fordi kontrollermetoden som håndterer forespørselen må skrive hint forespørselsobjektet i signaturen, slik at det automatisk kan validere innkommende skjemadata (som spesifisert i regler()-metoden. Mer om det senere...) For nå, la oss bruke håndverkerkommandoen igjen for å generere forespørselstubben vår:

php artisan make:request UploadFileRequest

Denne kommandoen vil generere en fil kalt UploadFileRequest inne i app/Http/Requests/UploadFileRequest. Åpne stubben og ta en titt... Du vil finne det veldig enkelt, og inneholder bare to metoder, autorisere() og regler.

Opprette valideringslogikken

La oss endre forespørselstubben for å møte behovene til applikasjonen vår. Endre filen slik at den ser slik ut:

<?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 endringer, men legg merke til at authorize()-metoden nå returnerer true i stedet for usant. Denne metoden avgjør om forespørselen skal gå inn i applikasjonen eller ikke. Hvis den er satt til usann, stopper den forespørselen fra å komme inn i systemet (som normalt vil være en metode på kontrolleren). Dette ville være et veldig praktisk sted å sette autorisasjonssjekker på brukeren eller annen logikk som kan avgjøre om forespørselen kan gå videre til kontrolleren. Foreløpig går vi bare tilbake her for å la alt og alt bruke forespørselen.

Den andre metoden, regler() er der all magien spiller inn med hensyn til validering. Ideen er enkel: returner en matrise som inneholder et sett med regler i form av:

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

Det er mange forskjellige valideringsbegrensninger som støttes av Laravel rett ut av boksen. For en fullstendig liste over dem, sjekk ut den elektroniske dokumentasjonen her.. For opplastingsapplikasjonen vår kommer det til å være to felt som sendes inn via POST-forespørsel fra et skjema i grensesnittet. FileName-parameteren må inkluderes inne i skjemateksten (dvs. nødvendig) og brukes som filnavnet vi skal lagre filen under i lagringen (dette gjøres i kontrolleren – vi kommer til det litt senere). Vi spesifiserer også at filnavnet må være en streng ved å legge til et rørtegn (|) og ordet 'streng'. Begrensninger er alltid avgrenset av rør, slik at du kan spesifisere eventuelle tilleggskriterier for det gitte feltet på en enkelt linje! Hvilken kraft!

Den andre parameteren, userFile , er den faktiske filen som brukeren laster opp fra et skjema på en nettside. UserFile er også nødvendig og må være en fil. OBS: Hvis vi forventet at den opplastede filen skulle være et bilde, ville vi brukt bildebegrensningen i stedet, som ville begrense filtypene som godtas til å være en av de populære bildetypene (jpeg, png, bmp, gif eller svg). Siden vi ønsker å la brukeren laste opp hvilken som helst type fil, vil vi bare holde oss til filvalideringsbegrensningen.

Det er omtrent alt som er til forespørselsobjektet. Hovedoppgaven er ganske enkelt å holde det akseptable settet med kriterier (begrensninger) som skjemaets kroppsparametere må tilfredsstille for å gå dypere inn i søknaden. En annen ting å merke seg er at disse to feltene (brukerfil og filnavn) også må spesifiseres inne i HTML-koden i form av inndatafelt (med feltnavnet som tilsvarer navnet inne i forespørselsobjektet).

Du spør kanskje: sikker på at dette definerer egenskapene til hva en skjemaforespørsel skal inneholde, men hvor gjøres den faktiske kontrollen av disse begrensningene? Vi kommer inn på det neste.

Modifisering av kontrolleren

Åpne appen/Http/Controllers/UploadController og gjør følgende endringer i den:

<?php

namespace App\Http\Controllers;

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

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

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

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

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

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

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

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

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

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

Så det er en ganske enkel tilnærming til å lagre de opplastede filene til disk. Her er en oversikt over upload()-metoden ovenfor:

• Skriv inn forespørselsklassen i kontrollermetoden som utfører funksjonaliteten "kjøtt og poteter", slik at vi kan autovalidere innkommende data
• Ta filen ut av (nå validert) forespørselsobjektet inne i kontrollermetoden (i dette tilfellet har vi kalt den upload(), men den kunne også ha fått et mer standardisert navn som store()).
• Ta filnavnet ut av forespørselen
• Generer det endelige filnavnet som skal brukes til å lagre filen under. GetClientOriginalExtension()-metoden tar ganske enkelt tak i den opprinnelige utvidelsen av den opplastede filen.
• Lagre filen til det lokale filsystemet ved å bruke dens storeAs()-metode, og send inn den navngitte banen inne i /storage-katalogen som det første argumentet og filnavnet som skal lagres under som det andre.
• Returner et JSON-svar som indikerer at forespørselen var vellykket

Bladmalen

Den siste store biten i dette puslespillet er bladmalen, som vil inneholde all HTML, CSS og javascript for vår enkle applikasjon. Her er koden – vi vil forklare den senere.

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

Her er hva vår / laste opp siden ser slik ut:

Dette er et veldig typisk eksempel på en bladfil som inneholder et HTML-skjema og javascript/jQuery for å legge til asynkron funksjonalitet (slik at siden ikke oppdateres). Det er en grunnleggende tag uten metodeattributt (som jeg skal forklare om et sekund) og med et nysgjerrig handlingsattributt med verdien {{route('file.upload')}}. I blad er dette det som er kjent som en Direktivet. Et direktiv er bare et fancy navn på funksjon - de er funksjoner som er spesifikke for bladmaler som utfører forskjellige operasjoner som er felles for å lage nettsider og nettapplikasjoner. For en bedre forståelse av alt den kule dritten som blad kan gjøre, sjekk ut dokumentene her.. I tilfellet ovenfor bruker vi rutedirektivet til å generere en URL for innsending av skjema.

Husk at vi definerte rutene våre tidligere i applikasjonen i web.php-filen, og spesifiserte et lett å huske navn for hver av dem. {{route()}}-direktivet godtar et navn på en rute, slår det opp i den internt bufrede rutelisten, og genererer en fullstendig URL basert på definisjonen av ruten i web.php-filen. For dette første tilfellet spesifiserer vi at vi vil at skjemaet skal sende innsendte data til /process URL for søknaden vår, som er definert som en POST rute.

Det neste rare du kanskje har lagt merke til er @csrf-taggen rett under åpningsskjemaet. I blade genererer denne taggen en _token-parameter på skjemaet, som blir sjekket inne i applikasjonen før skjemadataene tillates behandlet. Dette sikrer at dataene i skjemaet er av gyldig opprinnelse og forhindrer angrep på tvers av nettsteder. For mer informasjon om dette, se docs.

Etter dette definerer vi skjemaet vårt som normalt, men vær oppmerksom på at navnene på skjemaparameterne våre, brukerfil og filnavn er nøyaktig samme som definert i vårt forespørselsobjekt. Hvis vi glemte å inkludere en inndata for en gitt parameter som var definert i forespørselsobjektet (eller feilstavet det), ville forespørselen mislykkes og en feil vil bli returnert, noe som hindrer den opprinnelige skjemaforespørselen fra å treffe kontrollermetoden som ligger på UploadController@ prosess.

Gå videre og prøv det og send inn noen få filer til søknaden ved å bruke dette skjemaet. Etterpå, naviger til /liste side for å se innholdet i opplastingsmappen, med filene du lastet opp i en tabell:

The Bigger Picture

La oss ta et skritt tilbake og se på hva vi har gjort i denne Laravel-opplæringen.

Dette diagrammet viser applikasjonen slik den står akkurat nå (høynivådetaljer ekskludert):

Du bør huske at forespørselsobjektet vi konstruerte i begynnelsen av denne Laravel-opplæringen bør ha de samme parameterne definert i regelmetoden som er på skjemaet i bladmalen (hvis ikke les avsnittet "Opprette valideringslogikken") på nytt. . Brukeren legger inn skjemaet på en nettside som gjengis via en bladmalmotor (denne prosessen er selvfølgelig på autopilot så vi trenger ikke engang tenke på det) og sender inn skjemaet. Malens jQuery-kode nederst stopper standardinnsendingen (som automatisk vil omdirigere til en egen side), oppretter en ajax-forespørsel, laster forespørselen med skjemadata og laster opp filen, og sender det hele til det første laget av vår søknad: forespørselen.

Forespørselsobjektet blir fylt ut ved å assosiere parameterne inne i rule()-metoden med de innsendte skjemaparameterne, og deretter validere dataene i henhold til hver spesifisert regel. Hvis alle reglene er oppfylt, sendes forespørselen videre til hvilken som helst kontrollermetode som tilsvarer verdiene definert i rutefilen web.php. I dette tilfellet er det process()-metoden til UploadController som gjør jobben. Når vi har truffet kontrolleren, vet vi allerede at forespørselen bestod valideringen, så vi trenger ikke å teste på nytt om filnavnet som er gitt faktisk er en streng eller userFile-parameteren faktisk inneholder en type fil... Vi kan fortsette som normal.

Kontrollermetoden henter deretter de validerte parametrene ut av forespørselsobjektet, genererer et fullstendig filnavn ved å sette sammen parameteren som er sendt i filnavn med brukerfilens opprinnelige utvidelse, lagrer filen i en katalog i applikasjonen vår, og returnerer deretter en enkel JSON-kodet svar som bekrefter at forespørselen var vellykket. Svaret mottas av jQuery-logikken, som utfører noen flere brukergrensesnitt-relaterte oppgaver, for eksempel å vise suksess- (eller feil)-meldingen i 5 sekunder og deretter skjule den i tillegg til å slette tidligere skjemaoppføringer ... dette er slik at brukeren vet for sikker på at forespørselen var vellykket og kan laste opp en annen fil, hvis de ønsker det.

Legg også merke til i diagrammet ovenfor hvor linjen er trukket mellom klienten og serveren. Dette konseptet er helt avgjørende for deg å forstå og vil hjelpe deg med å løse problemer og problemer du kan ha i fremtiden når du sjonglerer, for eksempel, flere asynkrone forespørsler som kan oppstå til enhver tid. Separasjonen er rett ved grensen til forespørselsobjektet. Selve forespørselsobjektet kan betraktes som "porten" til resten av applikasjonen... Det utfører den første valideringen og registreringen av skjemaverdier som sendes inn fra nettleseren. Hvis de anses gyldige, fortsetter det til kontrolløren. Alt før det er på forsiden («klienten» betyr bokstavelig talt «på brukerens datamaskin»). Svaret returneres fra appen tilbake til klientsiden, der jQuery-koden vår tålmodig lytter etter dens ankomst og utfører noen enkle brukergrensesnittoppgaver når den mottar den.

Vi har dekket nesten 90+ viktige ofte spurte Laravel og PHP relaterte intervjuspørsmål for ferskinger så vel som erfarne kandidater for å få den rette jobben.