Laravel-opplæring for nybegynnere

Hva er Laravel?

Laravel er et åpen kildekode-web MVC-rammeverk for PHP. Laravel er et robust rammeverk som gir enkel utvikling av PHP-nettapplikasjoner med funksjoner som et modulært pakkesystem med en dedikert avhengighetsbehandling, tilgang til relasjonsdatabaser og andre verktøy for applikasjonsdistribusjon og vedlikehold.

Laravel ble laget av Taylor Otwell. Siden den første lanseringen i juni 2011 (versjon 1) har den jevnt og trutt blitt mer og mer populær innen PHP-rammeverksektoren i webutviklingsbransjen. Mye av denne populariteten kan tilskrives de mange utviklerfokuserte funksjonene som den leveres med som standard.

Hvorfor Laravel?

Cirka 2000, de fleste PHP -kode 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 utvikle seg til et vedlikeholdsmareritt. Verden trengte noe bedre. Så kom PHP versjon 5 og en rekke PHP-rammeverk som forsøkte å bringe tiltrengt struktur og bedre løsninger på ulike webapplikasjonsproblemer.

Siden den gang har vi sett mange rammeverk bli utgitt som banet vei for de populære rammeverkene som er i bruk i dag. I dag er de tre beste (etter vår mening) Zend Framework, Symfony og selvfølgelig Laravel. Selv om hvert av disse rammeverkene ble basert på lignende prinsipper og er rettet mot å løse (i utgangspunktet) de samme vanlige problemene, ligger de viktigste forskjellene i implementeringene. De har hver sine særegenheter når det gjelder hvordan man skal løse problemer. Når du ser på koden som produseres 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 den forskjellen mellom Laravel og CodeTenner.

Hvordan laste ned og installere Laravel med Composer

OBS: Denne veiledningen ble skrevet for Laravel 5.8, men rutings-, kontroller-, forespørsels- og bladkonseptene forblir de samme i nåværende utgivelser. Fra og med 2026 er den nyeste versjonen Laravel 13 (utgitt mars 2026), som krever PHP 8.3 eller nyere, mens Laravel 12 krever PHP 8.2.

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

OBS: For mer omfattende instruksjoner om hvordan du konfigurerer Laravel, se Laravel-dokumentasjonen. her..

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

composer global require laravel/installer

Som vil se omtrent slik ut:

Dette vil laste ned og installere alle rammeverksfilene i tillegg til alle avhengigheter som kreves. Pakkene lagres i leverandørkatalogen. Når det er nedlastet og installert, er det like enkelt som å utføre følgende kommando:

laravel new uploadApp

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

Composer installerer alle pakkene Laravel trenger for å kjøre. Det kan ta noen minutter, så vær tålmodig. Etter at det 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 programkoden vår ligger. Alle kontrollere, policyer og modeller ligger i denne mappen.
• bootstrap/ : Inneholder programmets oppstartsskript og noen få klassekartfiler.
• config/ : Inneholder appens konfigurasjonsfiler. Disse endres vanligvis ikke direkte, men er i stedet avhengige av verdiene som er satt opp i .env-filen (miljøfilen) i roten av appen.
• database/ : Huser databasefilene, inkludert migrasjoner, frø og testfabrikker.
• offentlig/ : Offentlig tilgjengelig mappe som inneholder kompilerte ressurser og, selvfølgelig, en index.php-fil.
• ressurser/ : Inneholder frontend-ressurser som JavaSkriptfiler, språkfiler, CSS/SASS-filer og alle maler som brukes i applikasjonen (kalt bladmaler).
• ruter/: Alle rutene i applikasjonen finnes her. Det finnes noen forskjellige «omfang» av ruter, men den vi skal fokusere på er web.php-filen.
• lagring/ : Alle midlertidige hurtigbufferfiler som brukes av applikasjonen, øktfiler, kompilerte visningsskript og loggfiler.
• tester/: Inneholder testfiler for applikasjonen, for eksempel enhetstester og funksjonstester.
• leverandør/: Alle avhengighetspakker ble installert med composer.

La oss nå bygge resten av appen og kjøre den med en spesiell artisan-kommando (for å spare oss bryet med å installere og konfigurere en webserver som Apache eller nginx). .env-filen inneholder alle konfigurasjonsverdiene som filene i /config-katalogen bruker for å konfigurere applikasjonen.

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. vis de tidligere opplastede filene på en annen side.

For dette prosjektet vil applikasjonen vår være skrivebeskyttet, 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 opp Laravel-ferdighetene og kunnskapen din. Merk at vi for korthets skyld har ekskludert all databasemodellering, migreringer og autentisering, men i en applikasjon i den virkelige verden er dette ytterligere 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 der logikken for å lagre den opplastede filen befinner seg.
• A controller som håndterer forespørsel-til-svar-flyten.
• A mal som vil bli brukt til å vise en liste over tidligere opplastede filer og selve opplastingsskjemaet.
• A anmode som den behandlingsansvarlige vil bruke til å validere dataene som sendes inn fra nettskjemaet.

Hva er en rute?

En rute i Laravel er i bunn og grunn et endepunkt spesifisert av en URI som fungerer som en «peker» til en funksjonalitet som tilbys av applikasjonen. Vanligvis peker en rute ganske enkelt til en metode på en kontroller og dikterer også hvilke HTTP-metoder som kan treffe den URI-en. En rute betyr heller ikke alltid en kontrollermetode; den kan også bare sende kjøringen av applikasjonen til en definert Closure eller anonym funksjon.

Hvorfor bruke en 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 offentlig tilgjengelige «nettleserbaserte» rutene. Disse er de vanligste og det er de som blir truffet av nettleseren. De kjører gjennom web middleware-gruppen og inneholder også fasiliteter for CSRF-beskyttelse (som bidrar til å forsvare seg mot skjemabaserte ondsinnede angrep) og inneholder generelt en grad av «tilstand» (med dette mener vi at de bruker økter).
• api.php: ruter som korresponderer med en API-gruppe og dermed har API-mellomvare aktivert som standard. Disse rutene er tilstandsløse og har ingen økter eller minne for kryssforespørsler (én forespørsel deler ikke data eller minne med noen annen forespørsel; hver enkelt er selvinnkapslet).
• console.php: disse rutene samsvarer med tilpassede artisan-kommandoer du har opprettet for appen din.
• channels.php: registrerer ruter for kringkasting av arrangementer.

Den viktigste filen å være oppmerksom på nå er den nettleserspesifikke, web.php. Det er allerede definert én rute som standard, som er den du trykker på til høyre når du navigerer til webroten til applikasjonen din (webroten 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: Det er her skjemaet som ligger på /upload URI-en legger inn sine innsendte skjemadata (skjemaets «handling»).
• /liste: dette vil liste opp alle filer som er lastet opp til nettstedet.

OBS: Sluttpunktet /list er kanskje ikke nødvendig hvis vi ønsker å legge all logikken for å vise opplastingsskjemaet og fillisten på én side. Vi har imidlertid holdt dem separate foreløpig for å legge til litt mer innhold i 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 veiledningen for Laravel-rammeverket vil vi for hver ønsket rute liste den eksplisitt opp 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 ut. Det disse metodene gjør er å spesifisere hvilke HTTP-verb som har tilgang til den gitte ruten. Hvis du trenger at en rute skal kunne godta mer enn ett HTTP-verb (noe som kan være tilfelle hvis du bruker én enkelt side til både å vise de opprinnelige dataene og dataene fra det innsendte skjemaet), kan du bruke Route::any()-metoden.

Det andre argumentet til både Route::get()- og Route::post()-metodene (og alle andre HTTP-verb-relaterte metodene på Route-fasaden) er navnet på en spesifikk kontroller og metoden som ligger i den kontrolleren, og som kjøres når den treffer rutens endepunkt med den tillatte HTTP-forespørselen (GET, POST, PATCH osv.). Vi bruker UploadController for alle rutene og har spesifisert dem på følgende måte:

Den siste metoden vi kaller på hver rute er dens name()-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 upload, process og list). Det virker kanskje ikke som en så god funksjon å gi hver rute sitt eget navn når URL har nøyaktig samme navn, men det er veldig nyttig 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 tjenestecontainer.
• De gir en kortfattet, minneverdig syntaks som lar deg bruke Laravels funksjoner uten å huske lange klassenavn som må injiseres eller konfigureres manuelt.

I rutedefinisjonene ovenfor 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 deg.pingFasader brukes mye i Laravel-rammeverket; du kan og bør bli mer kjent med dem. Dokumentasjonen for fasader finner du her. 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 den grunnleggende definisjonen og er også minimumskravet til en gitt kontroller. Det den gjør mellom disse to tingene regnes generelt som kontrollerens "handling" (eller "rutens implementering"). Den fungerer som det andre inngangspunktet til applikasjonen (det første er forespørselen) for klienten, som sender forespørselsnyttelasten (som vi kommer til senere) til applikasjonen, i forventning om en eller annen form for respons (i form av en suksessside, omdirigering, feilside eller en hvilken som helst annen type HTTP-respons).

En kontroller gjør (i utgangspunktet) det samme som en rutedefinisjon med en anonym funksjon satt som "handling" når ruten blir truffet. Forskjellen er at en kontroller holder seg godt til separasjonen av bekymringer, mens en rute er definert i tråd med den faktiske ruten. URL definisjon, som i utgangspunktet betyr at vi kobler rutens tildelte URI med rutens implementering, eller koden som kjøres når den ruten blir truffet.

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 nr. 2: Rutens definisjon ligger i 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 nr. 2 virker som mye mer arbeid (noe det ikke er, bare litt mer kode), bør du se på fordelene vi får ved å plassere handlingslogikken vår for den gitte «hello-world»-ruten inne i en kontroller i stedet for med rutens definisjon som en tilbakeringingsfunksjon:

1. Logikken vår er tydelig delt inn i sin egen klasse (separasjon av bekymringer).
2. Kontrolleren vår er satt opp for utvidelse senere hvis vi trenger å legge til flere funksjoner. La oss si at vi ønsker å legge til en «farvelverden»-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 URI-er til riktig metode på kontrolleren. Dette er ønskelig sammenlignet med å fylle 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 i applikasjonen er konfigurert ved hjelp av kontrollerspesifikke kart.pings (se eksempel nr. 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 stub for en kontroller kalt «UploadController» i hovedkatalogen for kontroller på /app/Http/Controllers/UploadController.php. Åpne gjerne den filen og ta en titt. Den er veldig enkel fordi den bare er en stubbet versjon av kontrolleren, med riktig navneromsbane og de nødvendige klassene den strekker seg fra.

Genererer forespørselen

Før vi går videre i denne PHP Laravel-opplæringen og gjør noen endringer i UploadControllers genererte stub, vil det være mer fornuftig å opprette request-klassen først. Dette er fordi controller-metoden som håndterer forespørselen må typehinte request-objektet i signaturen sin, slik at den automatisk kan validere de innkommende skjemadataene (som spesifisert i rules()-metoden; mer om det senere). La oss nå bruke artisan-kommandoen igjen for å generere request stub-en vår:

php artisan make:request UploadFileRequest

Denne kommandoen vil generere en fil kalt UploadFileRequest i app/Http/Requests/UploadFileRequest. Åpne stubben og ta en titt. Du vil finne den veldig enkel, den inneholder bare to metoder, authorize() og rules().

Opprette valideringslogikken

La oss endre forespørselsstubben slik at den møter 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 false. Denne metoden bestemmer om forespørselen skal tillates å gå inn i applikasjonen eller ikke. Hvis den er satt til false, stopper den forespørselen fra å komme inn i systemet. Dette ville være et veldig nyttig sted å sette autorisasjonskontroller på brukeren eller annen logikk som kan avgjøre om forespørselen kan gå videre til kontrolleren. Foreløpig returnerer vi bare true her for å tillate alt å bruke forespørselen.

Den andre metoden, rules(), er der all magien kommer inn i bildet når det gjelder validering. Ideen er enkel: returner en array 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 skal det være to felt som sendes inn via en POST-forespørsel fra et skjema i frontenden. Parameteren fileName må inkluderes i skjemaets brødtekst (dvs. obligatorisk) og brukes som filnavnet vi lagrer filen under i lagringen (dette gjøres i kontrolleren; vi kommer tilbake 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å én linje.

Den andre parameteren, userFile, er den faktiske filen som brukeren laster opp fra et skjema på en nettside. userFile er også obligatorisk, og må være en fil. OBS: Hvis vi forventet at den opplastede filen skulle være et bilde, ville vi i stedet brukt bildebegrensningen, som ville begrense filtypene som aksepteres som en av de populære bildetypene (jpeg, png, bmp, gif eller svg). Siden vi ønsker å tillate brukeren å laste opp alle typer filer, holder vi oss bare til filvalideringsbegrensningen.

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

Du lurer kanskje på: dette definerer hva en skjemaforespørsel skal inneholde, men hvor skjer den faktiske kontrollen av disse begrensningene? Det skal vi se nærmere på senere.

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 process(UploadFileRequest $request)
{
//At this point, the parameters passed into the $request (from form) are
//valid--they satisfy each of the conditions inside the rules() method

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

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

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

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

Så det er en ganske enkel metode for å lagre de opplastede filene på disk. Her er en oversikt over process()-metoden ovenfor:

• Type-hint forespørselsklassen i kontrollermetoden som utfører hovedfunksjonaliteten, slik at vi kan automatisk validere de innkommende dataene.
• Hent filen fra det (nå validerte) forespørselsobjektet i kontrollermetoden.
• Hent 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 brikken i dette puslespillet er bladmalen, som vil inneholde all HTML, CSS og JavaSkript for vår enkle applikasjon. Her er koden; vi skal forklare den senere.

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

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

Dette er et veldig typisk eksempel på en bladfil som inneholder et HTML-skjema og JavaSkript/jQuery for å legge til asynkron funksjonalitet (slik at siden ikke oppdateres). Det er en grunnleggende tag uten metodeattributt (som vi skal forklare om et øyeblikk) og med et curious action-attributt med verdien {{route('process')}}. I blade er dette det som kalles en Direktivet. Et direktiv er bare et fancy navn på en funksjon; det er funksjoner som er spesifikke for blade-maler som utfører forskjellige operasjoner som er vanlige for å konstruere nettsider og webapplikasjoner. For en bedre forståelse av alle de nyttige tingene blade kan gjøre, sjekk ut dokumentasjonen. her.I tilfellet ovenfor bruker vi rutedirektivet til å generere en URL for innsending av skjemaet vårt.

Husk at vi definerte rutene våre tidligere i applikasjonen i web.php-filen, og spesifiserte et navn som er lett å huske for hver av dem. Direktivet {{route()}} godtar navnet på en rute, slår det opp i den internt hurtigbufrede rutelisten og genererer en fullstendig [fil/etc.]. URL basert på definisjonen av den ruten i web.php-filen. I dette første tilfellet spesifiserer vi at vi ønsker at skjemaet skal sende de innsendte dataene til /process URL av applikasjonen vår, som er definert som en POST rute.

Det neste du kanskje har lagt merke til er @csrf-taggen rett under den første skjemataggen. I blade genererer denne taggen en _token-parameter på skjemaet, som sjekkes i applikasjonen før skjemadataene får lov til å bli behandlet. Dette sikrer at dataene i skjemaet har en gyldig opprinnelse og forhindrer forfalskningsangrep på tvers av nettsteder. For mer informasjon om dette, se docs.

Etter dette definerer vi skjemaet vårt som normalt; merk imidlertid at navnene på skjemaparametrene våre, brukerfil og filnavn, er nøyaktig samme som definert i vårt forespørselsobjekt. Hvis vi glemte å inkludere input for en gitt parameter som var definert i forespørselsobjektet (eller stavet det feil), ville forespørselen mislykkes og en feil ville bli returnert, noe som forhindret den opprinnelige skjemaforespørselen fra å noen gang treffe kontrollermetoden som ligger på UploadController@process.

Prøv det ut, og send inn noen filer til applikasjonen ved hjelp av dette skjemaet. Gå deretter 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 er akkurat nå (detaljer på overordnet nivå er ekskludert):

Du bør huske at forespørselsobjektet vi konstruerte i begynnelsen av denne Laravel-opplæringen, skal ha de samme parameterne definert i regelmetoden som er på skjemaet i bladmalen (hvis ikke, les avsnittet «Opprette valideringslogikken» på nytt). Brukeren skriver inn skjemaet på en nettside som gjengis via bladmalmotoren og sender inn skjemaet. Malens jQuery-kode nederst stopper standardinnsendingen (som automatisk omdirigerer til en egen side), oppretter en ajax-forespørsel, laster inn forespørselen med skjemadataene og den opplastede filen, og sender hele greia til det første laget av applikasjonen vår: forespørselen.

Request-objektet fylles ut ved å assosiere parameterne i rules()-metoden med de innsendte skjemaparametrene, og validerer deretter dataene i henhold til hver spesifisert regel. Hvis alle reglene er oppfylt, sendes forespørselen videre til den kontrollermetoden som samsvarer med verdiene definert i rutefilen web.php. I dette tilfellet er det process()-metoden til UploadController som gjør jobben. Når vi når kontrolleren, vet vi allerede at forespørselen har bestått valideringen, så vi trenger ikke å teste på nytt om det oppgitte filnavnet faktisk er en streng eller om userFile-parameteren faktisk inneholder en eller annen filtype. Vi kan fortsette som normalt.

Kontrollermetoden henter deretter de validerte parameterne fra forespørselsobjektet, genererer et fullstendig filnavn ved å sammenkoble den sendte fileName-parameteren med userFiles opprinnelige filendelse, lagrer filen i en katalog i applikasjonen vår, og returnerer deretter et enkelt JSON-kodet svar som bekrefter at forespørselen var vellykket. Svaret mottas av jQuery-logikken, som utfører noen flere brukergrensesnittrelaterte oppgaver, som å vise suksessmeldingen (eller feilmeldingen) i 5 sekunder, deretter skjule den, samt slette de tidligere skjemaoppføringene. Dette er slik at brukeren vet sikkert at forespørselen var vellykket og kan laste opp en annen fil hvis de ønsker det.

Legg også merke til i diagrammet ovenfor hvor grensen går mellom klienten og serveren. Dette konseptet er helt avgjørende for deg å forstå, og det vil hjelpe deg med å løse problemer og utfordringer du måtte ha i fremtiden når du for eksempel sjonglerer 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 som gyldige, fortsetter det til kontrolleren. Alt før det er på front-end («klienten» betyr bokstavelig talt «på brukerens datamaskin»). Svaret returneres fra appen tilbake til klientsiden, hvor jQuery-koden vår tålmodig lytter etter ankomsten og utfører noen få enkle brukergrensesnittoppgaver når den mottar den.

Vi har også dekket mange viktige ofte stilte spørsmål Laravel og PHP relaterte intervjuspørsmål for ferskinger så vel som erfarne kandidater for å få den rette jobben.

Spørsmål og svar