Laravel opetusohjelma aloittelijoille

Mikä on Laravel?

Laravel on avoimen lähdekoodin web MVC -kehys PHP:lle. Laravel on vankka kehys, joka tarjoaa helpon PHP-verkkosovellusten kehittämisen ominaisuuksilla, kuten modulaarisella pakkausjärjestelmällä, jossa on oma riippuvuushallinta, pääsy relaatiotietokantoihin ja muihin apuohjelmiin sovellusten käyttöönottoa ja ylläpitoa varten.

Laravelin loi Taylor Otwell. Julkaisustaan ​​kesäkuussa 2011 (versio 1) lähtien se on tasaisesti kasvattanut suosiotaan PHP-kehysten sektorilla web-kehitysalalla. Suuri osa tästä suosiosta voidaan katsoa johtuvan monista kehittäjäkeskeisistä ominaisuuksista, jotka siinä on oletuksena.

Miksi Laravel?

Noin 2000, suurin osa PHP koodi oli menettelyllinen, ja se voi löytyä "skriptien" muodossa, joissa olisi sotkuinen spagettikoodi. Jopa yksinkertaisimmilla sivuilla ei ollut huolenaiheiden erottaminen toisistaan, ja näin ollen sovelluksen oli melko helppo nopeasti kasvaa ylläpidon painajaiseksi. Maailma tarvitsi jotain parempaa. Esiin astui PHP-versio 5 ja useat PHP-kehykset, jotka pyrkivät tuomaan kaivattua rakennetta ja parempia ratkaisuja erilaisiin verkkosovellusten ongelmiin.

Siitä lähtien olemme nähneet monia frameworkeja, jotka tasoittivat tietä nykyään käytössä oleville suosituille frameworkeille. Nykyään kolme parasta olisivat (mielestämme) Zend Framework, Symfony ja tietenkin Laravel. Vaikka jokainen näistä frameworkeista perustuu samankaltaisiin periaatteisiin ja on suunnattu ratkaisemaan (periaatteessa) samoja yleisiä ongelmia, niiden keskeiset erot ovat toteutuksissa. Jokaisella on omat omituisuutensa ongelmien ratkaisemisessa. Kun tarkastelet kunkin tuottamaa koodia, huomaat, että niiden välillä on melko selkeä raja. Vaatimattoman mielipiteemme mukaan Laravel-framework on paras.

Lue lisää ero Laravelin ja muiden välillä Codesytytin.

Kuinka ladata ja asentaa Laravel Composerilla

Huomautus: Tämä tutoriaali on kirjoitettu Laravel 5.8:lle, mutta reititys-, ohjain-, pyyntö- ja Blade-konseptit pysyvät samoina nykyisissä julkaisuissa. Vuonna 2026 uusin versio on Laravel 13 (julkaistu maaliskuussa 2026), joka vaatii PHP 8.3:n tai uudemman, kun taas Laravel 12 vaatii PHP 8.2:n.

Huomautus: Oletetaan, että sinulla on jo PHP asennettuna paikalliseen järjestelmään. Jos ei, voit lukea ohjeet sen asentamiseen. täältä.

Composer on sekä paketti- että riippuvuushallinta. Asenna se avaamalla pääte ja CD-levy uuteen hakemistoon. Suorita tämä komento:

curl -Ss getcomposer.org/installer | php

Tämän komennon tulokset näyttävät tältä:

Huomautus: Katso tarkemmat ohjeet Laravelin asentamiseen Laravelin dokumentaatiosta. täältä.

Näet sen lataavan ja kääntävän composer.phar-skriptin, jota käytämme Laravelin asentamiseen. Vaikka uuden Laravel-sovelluksen voi asentaa monella eri tavalla, teemme sen Laravelin composer-skriptin avulla. Asentaaksesi tämän skriptin, suorita:

composer global require laravel/installer

Joka näyttää suunnilleen tältä:

Tämä lataa ja asentaa kaikki kehystiedostot sekä kaikki tarvittavat riippuvuudet. Paketit tallennetaan toimittajan hakemistoon. Kun se on ladattu ja asennettu, se on yhtä helppoa kuin seuraavan komennon antaminen:

laravel new uploadApp

Näet jotain seuraavanlaisen tulosteen kaltaista:

Composer asentaa kaikki Laravelin tarvitsemat paketit toimiakseen. Se voi kestää muutaman minuutin, joten ole kärsivällinen. Kun se on valmis, suorita ls -al -komento tarkistaaksesi asennetut paketit.

Tässä on lyhyt erittely yleisen Laravel-sovelluksen hakemistoista:

• sovellus/ : Tämä on lähdekoodikansio, jossa sovelluskoodimme sijaitsee. Kaikki ohjaimet, käytännöt ja mallit ovat tämän kansion sisällä.
• bootstrap/ : Sisältää sovelluksen käynnistysskriptin ja muutamia luokkakarttatiedostoja.
• config/ : Sisältää sovelluksen määritystiedostot. Näitä ei yleensä muokata suoraan, vaan ne perustuvat sovelluksen juuressa olevaan .env (ympäristö) -tiedostoon määritettyihin arvoihin.
• tietokanta/ : Sisältää tietokantatiedostot, mukaan lukien migraatiot, siemenet ja testitehtaat.
• julkinen/ : Julkisesti saatavilla oleva kansio, joka sisältää käännettyjä resursseja ja tietenkin index.php-tiedoston.
• resurssit/ : Sisältää käyttöliittymän resursseja, kuten JavaSkriptitiedostot, kielitiedostot, CSS/SASS-tiedostot ja kaikki sovelluksessa käytetyt mallit (joita kutsutaan blade-malleiksi).
• reitit/ : Kaikki sovelluksen reitit löytyvät täältä. Reittejä on muutamia erilaisia ​​"laajuusalueita", mutta keskitymme tässä web.php-tiedostoon.
• varastointi/ : Kaikki sovelluksen käyttämät väliaikaiset välimuistitiedostot, istuntotiedostot, käännetyt näkymäkomentosarjat ja lokitiedostot.
• testit/: Sisältää sovelluksen testitiedostoja, kuten yksikkötestejä ja toiminnallisia testejä.
• myyjä/: Kaikki riippuvuuspaketit asennetaan composerin mukana.

Nyt sitten rakennetaan loput sovelluksesta ja suoritetaan se erityisellä Artisan-komennolla (jotta säästyisimme web-palvelimen, kuten Apachen tai nginxin, asentamisen ja konfiguroinnin vaivalta). .env-tiedosto sisältää kaikki määritysarvot, joita /config-hakemiston tiedostot käyttävät sovelluksen konfigurointiin.

Sovellussuunnittelu: Vaatimuksemme nopea selvitys

Tässä Laravelin online-opetusohjelmassa rakennamme hyvin yksinkertaisen sovelluksen, joka tekee vain kaksi asiaa:

1. käsitellä tiedostojen latauksia verkkolomakkeesta
2. näyttää aiemmin ladatut tiedostot eri sivulla.

Tässä projektissa sovelluksemme on vain kirjoitusoikeutta käyttävä, mikä tarkoittaa, että käyttäjä voi vain kirjoittaa tiedostoja ja tarkastella lataamiensa tiedostojen luetteloa. Tämä sovellus on erittäin yksinkertainen, mutta sen pitäisi toimia hyvänä harjoituksena Laravel-taitojen ja -tietämyksen kehittämisen aloittamiseen. Huomaa, että lyhyyden vuoksi olemme jättäneet pois tietokantamallinnuksen, migraatiot ja todennuksen, mutta todellisessa sovelluksessa nämä ovat lisäasioita, jotka sinun kannattaa ottaa huomioon.

Tässä on luettelo komponenteista, joita tarvitsemme saadaksemme sovelluksen toimimaan odotetulla tavalla:

• A reitti joka sallii ulkomaailman (internetin) käyttää sovellusta ja määrittää päätepisteen, joka osoittaa ladatun tiedoston tallennuslogiikan sijaintiin.
• A ohjain joka käsittelee pyyntö-vastaus-prosessin.
• A sapluuna jota käytetään aiemmin ladattujen tiedostojen luettelon ja itse latauslomakkeen näyttämiseen.
• A pyyntö jota ohjain käyttää verkkolomakkeelta välitettyjen tietojen validointiin.

Mikä on reitti?

Laravelissa reitti on pohjimmiltaan URI:n määrittämä päätepiste, joka toimii "osoittimena" johonkin sovelluksen tarjoamaan toiminnallisuuteen. Yleisimmin reitti yksinkertaisesti osoittaa ohjaimen metodiin ja sanelee myös, mitkä HTTP-metodit voivat osua kyseiseen URI:in. Reitti ei aina tarkoita ohjaimen metodia; se voi yksinkertaisesti välittää sovelluksen suorituksen määritellylle Closure- tai anonyymille funktiolle.

Miksi käyttää reittiä?

Reitit tallennetaan tiedostoihin /routes-kansioon projektin juurihakemistossa. Oletusarvoisesti sovelluksen eri "puolia" vastaavia tiedostoja on muutama ("puolet" tulee kuusikulmaisen arkkitehtuurin metodologiasta). Niihin kuuluvat:

• web.php: julkisesti saatavilla olevat "selainpohjaiset" reitit. Nämä ovat yleisimmät ja ne joutuvat verkkoselaimen osumien kohteeksi. Ne kulkevat verkkoväliohjelmistoryhmän kautta ja sisältävät myös ominaisuuksia, jotka CSRF-suojaus (mikä auttaa puolustautumaan lomakepohjaisia ​​haitallisia hyökkäyksiä vastaan) ja yleensä sisältävät jonkin verran "tilaa" (tässä tarkoitamme, että ne käyttävät istuntoja).
• api.php: reitit, jotka vastaavat API-ryhmää ja joilla API-väliohjelmisto on siten oletuksena käytössä. Nämä reitit ovat tilattomia, eikä niillä ole istuntoja tai ristipyyntömuistia (yksi pyyntö ei jaa tietoja tai muistia minkään toisen pyynnön kanssa; jokainen pyyntö on itsekapseloitu).
• console.php: nämä reitit vastaavat sovelluksellesi luomiasi mukautettuja Artisan-komentoja.
• channels.php: rekisteröi reitit tapahtumien lähetystä varten.

Tärkein tiedosto, josta tässä vaiheessa on huolehdittava, on selainkohtainen tiedosto, web.php. Oletusarvoisesti on jo määritetty yksi reitti, joka on se, jota napsautat oikealla painikkeella siirryttäessäsi sovelluksesi web-juurihakemistoon (web-juurihakemisto on julkisessa hakemistossa). Tarvitsemme kolme eri reittiä, jotta lataussovelluksemme toimii:

• /upload: tämä on pääsivun URI, jolla näytetään verkkolomake tiedostojen lataamista varten.
• /process: tähän kohtaan /upload-URI-osoitteessa sijaitseva lomake lähettää lomakkeella lähetetyt tiedot (lomakkeen "toiminto").
• /list: tämä listaa kaikki sivustolle ladatut tiedostot.

Huomautus: /list-päätepistettä ei ehkä tarvita, jos haluamme sijoittaa kaikki latauslomakkeen ja tiedostoluettelon näyttämiseen tarvittavat tiedot yhdelle sivulle. Pidämme ne kuitenkin toistaiseksi erillään lisätäksemme hieman enemmän sisältöä käsillä olevaan aiheeseen.

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

Tässä Laravel-kehysopastuksessa listaamme jokaisen halutun reitin erikseen reittitiedostossa web.php käyttämällä yhtä käytettävissä olevista HTTP-kohtaisista pyyntömetodeista (get(), post(), put(), delete(), patch() tai options()). Katso erittely kustakin näistä tätä ulos. Nämä metodit määrittävät, millä HTTP-verbeillä on lupa käyttää tiettyä reittiä. Jos reitin on voitava hyväksyä useampi kuin yksi HTTP-verbi (mikä voi olla mahdollista, jos käytät yhtä sivua sekä alkuperäisten tietojen näyttämiseen että lähetettyjen lomaketietojen lähettämiseen), voit käyttää Route::any()-metodia.

Toinen argumentti sekä Route::get()- että Route::post()-metodeille (ja kaikille muille HTTP-verbiin liittyville Route-julkisivun metodeille) on tietyn ohjaimen nimi ja ohjaimen sisällä oleva metodi, joka suoritetaan, kun sallittu HTTP-pyyntö (GET, POST, PATCH jne.) osuu reitin päätepisteeseen. Käytämme UploadControlleria kaikille reiteille ja olemme määritelleet ne seuraavalla tavalla:

Viimeinen metodi, jota kutsumme kullekin reitille, on sen name()-funktio, joka hyväksyy yhden merkkijonon argumenttina ja jota käytetään enemmän tai vähemmän "tunnistamaan" tietty reitti helposti muistettavalla nimellä (tässä tapauksessa upload, process ja list). Ei ehkä vaikuta kovin hyvältä ominaisuudelta antaa jokaiselle reitille oma nimi, kun URL on nimetty täsmälleen samalla tavalla, mutta siitä on todella hyötyä, kun käytössä on tietty reitti, kuten /users/profile/dashboard/config, joka on helpompi muistaa muodossa profile-admin tai user-config.

Huomioita julkisivuista:

• Facadet tarjoavat "staattisen" rajapinnan sovelluksen palvelusäiliössä käytettävissä oleville luokille.
• Ne tarjoavat tiiviin, mieleenpainuvan syntaksin, jonka avulla voit käyttää Laravelin ominaisuuksia muistamatta pitkiä luokkien nimiä, jotka on lisättävä tai määritettävä manuaalisesti.

Yllä olevissa reittimääritelmissä käytämme Route-julkisivua sen sijaan, että luomme manuaalisesti uuden Illuminate/Routing/Router-objektin ja kutsumme vastaavia metodeja kyseiselle objektille. Se on vain oikotie, joka säästää aikaa.pingFacadeja käytetään paljon Laravel-kehyksessä; niihin kannattaa tutustua paremmin. Facadeja koskevat dokumentit löytyvät osoitteesta täältä.

Mikä on ohjain?

Ohjain on "C" "MVC" (Model-View-Controller) -arkkitehtuurissa, johon Laravel perustuu. Ohjaimen työ voidaan tiivistää tähän yksinkertaiseen määritelmään: se vastaanottaa pyynnön asiakkaalta ja palauttaa vastauksen asiakkaalle. Tämä on periaatteellinen määritelmä ja myös minkä tahansa ohjaimen vähimmäisvaatimus. Se, mitä se tekee näiden kahden asian välillä, katsotaan yleensä ohjaimen "toiminnoksi" (tai "reitin toteutukseksi"). Se toimii toisena saapumiskohtana sovellukseen (ensimmäinen on pyyntö) asiakkaalle, joka lähettää pyynnön hyötykuorman (johon palataan seuraavaksi) sovellukselle odottaen jonkinlaista vastausta (onnistumissivun, uudelleenohjauksen, virhesivun tai muun HTTP-vastauksen muodossa).

Ohjain tekee (periaatteessa) saman asian kuin reittimäärittely, jossa anonyymi funktio on asetettu "toiminnoksi", kun reittiin osutaan. Ero on siinä, että ohjain pitää huolen siitä, että vastuualueet on erotettu toisistaan, kun taas reitti määritellään varsinaisen reitin mukaisesti. URL määritelmä, mikä pohjimmiltaan tarkoittaa, että yhdistämme reitin määritetyn URI:n reitin toteutukseen eli koodiin, joka suoritetaan, kun kyseiseen reittiin osutaan.

Esimerkiksi seuraavat kaksi koodinpalaa saavuttavat saman asian:

Esimerkki 1: Reitin määrittely ja toteutus yhden menetelmäkutsun sisällä (web.php routes -tiedostossa)

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

Esimerkki 2: Reitin määritelmä on tiedostossa routes/web.php, mutta sen toteutus sijaitsee /app/Http/Controllers/HelloWorldController-luokassa.

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

Vaikka Laravel-esimerkki #2 vaikuttaa paljon työläämmältä (mitä se ei ole, vain hieman enemmän koodia), katsotaanpa etuja, joita saamme sijoittamalla tietyn "hello-world"-reitin toimintalogiikan ohjaimen sisälle sen sijaan, että reitti määriteltäisiin takaisinkutsufunktiona:

1. Logiikkamme on selkeästi eroteltu omaan luokkaan (huolenaiheiden erottelu).
2. Ohjaintamme on määritetty laajennettavaksi myöhemmin, jos siihen tarvitaan lisäominaisuuksia. Oletetaan, että haluamme lisätä "hyvästit maailma" -ominaisuuden. Tässä tapauksessa nimeämme ohjaimen uudelleen yleisemmäksi "HelloController"-muotoon ja määritämme sitten kaksi erillistä metodia, Hei() ja Hyvästi(). Meidän olisi myös määritettävä kaksi erillistä reittiä, jotka kartoittavat /Hei ja / Hyvästi URI:t niiden asianmukaiseen metodiin ohjaimessa. Tämä on toivottavaa verrattuna reittitiedoston lihottamiseen, jossa jokaisen reitin toteutus määritellään takaisinkutsufunktioiksi.
3. Laravelilla on sisäänrakennettu kyky tallentaa kaikki sovelluksen reittimääritykset välimuistiin, jotta se nopeuttaa tietyn reitin löytämiseen kuluvaa aikaa (lisää sovelluksen suorituskykyä); kuitenkin, voit hyödyntää sitä vain, jos kaikki sovelluksessa määritetyt reitit on konfiguroitu ohjainkohtaisen kartan avulla.pings (katso esimerkki 2 yllä).

Suoritetaan tämä komento, joka luo meille uuden ohjaimen.

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

Pohjimmiltaan tämä komento luo tynkän ohjaimelle nimeltä "UploadController" pääohjaimen hakemistossa osoitteessa /app/Http/Controllers/UploadController.php. Voit vapaasti avata tiedoston ja katsoa sitä. Se on hyvin yksinkertainen, koska se on vain tynkäversio ohjaimesta, jolla on oikea nimiavaruuden polku ja vaaditut luokat, joista se jatkuu.

Pyynnön luominen

Ennen kuin jatkamme tässä PHP Laravel -tutoriaalissa ja teemme muutamia muutoksia UploadControllerin luomaan tynkään, on järkevämpää luoda ensin request-luokka. Tämä johtuu siitä, että pyyntöä käsittelevän ohjainmetodin on tyyppivihjettävä request-objekti allekirjoituksessaan, jolloin se voi automaattisesti validoida saapuvat lomaketiedot (kuten rules()-metodissa on määritetty; lisää siitä myöhemmin). Käytämme nyt uudelleen artisan-komentoa pyyntötynkän luomiseen:

php artisan make:request UploadFileRequest

Tämä komento luo tiedoston nimeltä UploadFileRequest kansioon app/Http/Requests/UploadFileRequest. Avaa tynkä ja tutustu siihen. Se on hyvin yksinkertainen, sillä se sisältää vain kaksi metodia, authorize() ja rules().

Validointilogiikan luominen

Muokataan pyyntötynkää sovelluksemme tarpeiden mukaan. Muokkaa tiedostoa tältä näyttämään:

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

Ei paljoa muutoksia, mutta huomaa, että authorize()-metodi palauttaa nyt arvon true (tosi) eikä arvon false (epätosi). Tämä metodi päättää, sallitaanko pyynnön pääsy sovellukseen. Jos se asetetaan arvoon false (epätosi), se estää pyynnön pääsyn järjestelmään. Tämä olisi erittäin kätevä paikka asettaa käyttäjän valtuutustarkistuksia tai muita logiikoita, jotka voivat päättää, voiko pyyntö siirtyä eteenpäin ohjaimelle. Toistaiseksi palautamme tässä vain arvon true (tosi), jotta kaikki voi käyttää pyyntöä.

Toinen metodi, rules(), on se, missä kaikki validoinnin taika astuu esiin. Idea on yksinkertainen: palauta taulukko, joka sisältää joukon sääntöjä muodossa:

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

Laravel tukee monia erilaisia ​​vahvistusrajoituksia heti käyttöönoton jälkeen. Täydellinen luettelo niistä on online-dokumentaatiossa täältäLataussovelluksessamme on kaksi kenttää, jotka välitetään POST-pyynnön kautta käyttöliittymän lomakkeelta. fileName-parametrin on oltava lomakkeen rungon sisällä (eli pakollinen), ja sitä käytetään tiedostonimenä, jonka alle tallennamme tiedoston tallennustilaan (tämä tehdään ohjaimessa; palaamme siihen hieman myöhemmin). Määritämme myös, että tiedostonimen on oltava merkkijono, lisäämällä pystyviivan (|) ja sanan 'string'. Rajoitukset erotetaan aina pystyviivoilla, jolloin voit määrittää mahdolliset lisäehdot tietylle kentälle yhdellä rivillä.

Toinen parametri, userFile, on varsinainen tiedosto, jonka käyttäjä lataa verkkosivun lomakkeelta. userFile on myös pakollinen ja täytyy olla tiedosto. Huomautus: Jos odottaisimme ladattavan tiedoston olevan kuva, käyttäisimme kuvarajoitetta, joka rajoittaisi tiedostotyyppejä, jotka hyväksytään yhdeksi suosituimmista kuvatyypeistä (jpeg, png, bmp, gif tai svg). Koska haluamme antaa käyttäjän ladata minkä tahansa tyyppisiä tiedostoja, pidämme kiinni tiedoston validointirajoitteesta.

Siinäpä suunnilleen kaikki, mitä request-objektissa on. Sen päätehtävänä on yksinkertaisesti pitää sisällään hyväksyttävät kriteerit (rajoitteet), jotka lomakkeen runkoparametrien on täytettävä, jotta sovelluksessa voidaan edetä syvemmälle. Toinen huomionarvoinen asia on, että nämä kaksi kenttää (userFile ja fileName) on myös määritettävä HTML-koodin sisällä syöttökenttien muodossa (kentän nimen vastatessa request-objektin sisällä olevaa nimeä).

Saatat kysyä: tämä määrittelee lomakepyynnön sisällön ominaisuudet, mutta missä näiden rajoitusten varsinainen tarkistus tehdään? Palaamme siihen seuraavaksi.

Ohjaimen muokkaaminen

Avaa sovellus/Http/Controllers/UploadController ja tee siihen seuraavat muutokset:

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

Ladattujen tiedostojen tallentaminen levylle on siis melko yksinkertainen tapa. Tässä on erittely yllä olevasta process()-metodista:

• Kirjoita vihje pyyntöluokasta ohjainmetodiin, joka suorittaa päätoiminnon, jotta voimme automaattisesti validoida saapuvan datan.
• Hae tiedosto (nyt validoidusta) request-objektista ohjainmetodin sisällä.
• Ota tiedostonimi pyynnöstä.
• Luo lopullinen tiedostonimi, jota käytetään tiedoston tallentamiseen. GetClientOriginalExtension()-menetelmä yksinkertaisesti nappaa ladatun tiedoston alkuperäisen laajennuksen.
• Tallenna tiedosto paikalliseen tiedostojärjestelmään käyttämällä storeAs()-metodia ja välitä nimetty polku /storage-hakemiston sisällä ensimmäisenä argumenttina ja tiedostonimi, jonka alle se tallennetaan toiseksi.
• Palauttaa JSON-vastauksen, joka osoittaa pyynnön onnistuneen.

Blade-malli

Viimeinen tärkeä palanen tässä palapelissä on terämallipohja, joka sisältää kaikki HTML:n, CSS:n ja JavaSkripti yksinkertaiselle sovelluksellemme. Tässä on koodi; selitämme sen myöhemmin.

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

Tässä on mitä meidän / lataa sivu näyttää tältä:

Tämä on hyvin tyypillinen esimerkki HTML-lomakkeen sisältävästä blade-tiedostosta ja JavaSkripti/jQuery asynkronisen toiminnallisuuden lisäämiseksi (jotta sivu ei päivity). Peruskäyttöliittymä on käytettävissä. tagi ilman method-attribuuttia (jonka selitämme hetken kuluttua) ja omituisella action-attribuutilla, jonka arvo on {{route('process')}}. Bladessa tätä kutsutaan Direktiivi. Direktiivi on vain hieno nimi funktiolle; ne ovat Blade-malleille ominaisia ​​funktioita, jotka suorittavat erilaisia ​​toimintoja, jotka ovat yleisiä verkkosivujen ja verkkosovellusten rakentamisessa. Saadaksesi paremman käsityksen kaikista Bladen hyödyllisistä ominaisuuksista, tutustu dokumentaatioon. täältäYllä olevassa tapauksessa käytämme reittidirektiiviä luodaksemme URL lomakkeen lähettämistä varten.

Muista, että määrittelimme reittimme aiemmin sovelluksessa web.php-tiedostossa ja annoimme kullekin helposti muistettavan nimen. {{route()}}-direktiivi hyväksyy reitin nimen, etsii sen sisäisesti välimuistissa olevasta reittiluettelosta ja luo täyden... URL web.php-tiedostossa olevan reitin määritelmän perusteella. Tässä ensimmäisessä tapauksessa määritämme, että haluamme lomakkeen lähettävän lähetetyt tiedot /process-prosessiin. URL sovelluksestamme, joka on määritelty POST reittiä.

Seuraavaksi olet ehkä huomannut @csrf-tagin heti avauslomaketagin alapuolella. Bladessa tämä tagi luo lomakkeelle _token-parametrin, joka tarkistetaan sovelluksen sisällä ennen kuin lomakedatan käsittely sallitaan. Tämä varmistaa, että lomakkeen sisältämät tiedot ovat kelvollista alkuperää ja estää sivustojenväliset pyyntöväärennöshyökkäykset. Lisätietoja tästä on osoitteessa docs.

Tämän jälkeen määrittelemme lomakkeen normaaliksi; huomaa kuitenkin, että lomakeparametriemme nimet, userFile ja fileName, ovat täsmälleen sama kuten pyyntöobjektissamme on määritelty. Jos unohdimme sisällyttää syötteen tietylle pyyntöobjektissa määritellylle parametrille (tai kirjoitamme sen väärin), pyyntö epäonnistuu ja palautetaan virhe, mikä estää alkuperäistä lomakepyyntöä koskaan saavuttamasta UploadController@process-osoitteessa sijaitsevaa ohjainmetodia.

Kokeile sitä ja lähetä muutama tiedosto sovellukseen tällä lomakkeella. Siirry sen jälkeen kohtaan /lista -sivulta näet latauskansion sisällön ja lataamasi tiedostot on lueteltu taulukossa:

Bigger Picture

Otetaanpa askel taaksepäin ja katsotaanpa, mitä olemme tehneet tässä Laravel-tutoriaalissa.

Tämä kaavio kuvaa sovellusta sellaisena kuin se on tällä hetkellä (yleisen tason yksityiskohdat pois lukien):

Muista, että tämän Laravel-tutoriaalin alussa luomallamme request-objektilla tulisi olla samat rules-metodissa määritellyt parametrit kuin blade-mallipohjan lomakkeella (jos ei, lue uudelleen kohta ”Validointilogiikan luominen”). Käyttäjä syöttää lomakkeen verkkosivulle, joka renderöidään blade-mallipohjan kautta, ja lähettää lomakkeen. Mallipohjan jQuery-koodi lomakkeen alareunassa pysäyttää oletusarvoisen lähetyksen (joka ohjaa automaattisesti erilliselle sivulle), luo ajax-pyynnön, lataa pyynnön lomaketiedoilla ja ladatulla tiedostolla ja lähettää koko prosessin sovelluksemme ensimmäiseen kerrokseen: pyyntöön.

Pyyntöobjekti täytetään liittämällä rules()-metodin parametrit lähetettyihin lomakeparametreihin ja sitten se validoi tiedot kunkin määritetyn säännön mukaisesti. Jos kaikki säännöt täyttyvät, pyyntö välitetään sille ohjainmetodille, joka vastaa reittitiedostossa web.php määriteltyjä arvoja. Tässä tapauksessa työn suorittaa UploadControllerin process()-metodi. Kun ohjain on avattu, tiedämme jo, että pyyntö läpäisi validoinnin, joten meidän ei tarvitse testata uudelleen, onko annettu tiedostonimi todella merkkijono vai sisältääkö userFile-parametri jonkin tyyppistä tiedostoa. Voimme jatkaa normaalisti.

Ohjausmetodi hakee sitten validoidut parametrit pyyntöobjektista, luo täydellisen tiedostonimen yhdistämällä annetun fileName-parametrin userFile-parametrin alkuperäiseen tiedostopäätteeseen, tallentaa tiedoston sovelluksemme hakemistoon ja palauttaa sitten yksinkertaisen JSON-koodatun vastauksen, joka varmistaa pyynnön onnistumisen. jQuery-logiikka vastaanottaa vastauksen ja suorittaa muutamia käyttöliittymään liittyviä tehtäviä, kuten näyttää onnistumis- (tai virhe-)viestin viiden sekunnin ajan, piilottaa sen ja tyhjentää aiemmat lomakemerkinnät. Näin käyttäjä tietää varmasti, että pyyntö onnistui, ja voi halutessaan ladata uuden tiedoston.

Huomioi myös yllä olevasta kaaviosta, missä asiakkaan ja palvelimen välinen raja kulkee. Tämän käsitteen ymmärtäminen on ehdottoman tärkeää, ja se auttaa sinua ratkaisemaan ongelmia ja haasteita, joita saatat kohdata tulevaisuudessa, kun jonglööraat esimerkiksi useiden samanaikaisesti tapahtuvien asynkronisten pyyntöjen kanssa. Erottelu tapahtuu aivan pyyntöobjektin rajalla. Itse pyyntöobjektia voidaan pitää "porttina" muuhun sovellukseen. Se suorittaa verkkoselaimesta välitettyjen lomakearvojen alustavan validoinnin ja rekisteröinnin. Jos ne katsotaan kelvollisiksi, se jatkaa ohjaimeen. Kaikki sitä edeltävä on käyttöliittymässä ("asiakas" tarkoittaa kirjaimellisesti "käyttäjän tietokoneella"). Sovellus palauttaa vastauksen takaisin asiakaspuolelle, jossa jQuery-koodimme kuuntelee kärsivällisesti sen saapumista ja suorittaa muutamia yksinkertaisia ​​käyttöliittymätehtäviä vastaanotettuaan sen.

Olemme myös käsitelleet monia tärkeitä usein kysyttyjä kysymyksiä Laraveliin ja PHP:hen liittyvät haastattelukysymykset niin uusille kuin kokeneillekin hakijoille oikean työn saamiseksi.

UKK