Laravel opetusohjelma aloittelijoille

Laravelin loi Taylor Otwell. Alkuperäisen julkaisustaan ​​kesäkuussa 2011 (versio 1) lähtien se on kasvanut jatkuvasti suositummaksi web-kehitysteollisuuden PHP-kehyssektorilla. Suuri osa tästä suosiosta johtuu sen mukana toimitetuista monista kehittäjäystävällisistä ominaisuuksista.

Miksi Laravel?

Noin 2000, suurin osa PHP koodit oli menettelyllinen, ja se voi löytyä "skriptien" muodossa, joissa olisi sotkuinen spagettikoodi. Jopa yksinkertaisimmilla sivuilla ei ollut huolenaiheiden erottaminen toisistaan, ja siksi sovelluksesta oli melko helppo kasvaa nopeasti ylläpidon painajaiseksi. Maailma tarvitsi jotain parempaa… Anna PHP-versio 5 ja useita PHP-kehyksiä yrittääksesi tuoda kaivattua resoluutiota ja parempia ratkaisuja erilaisiin verkkosovellusongelmiin.

Sittemmin olemme nähneet monia kehyksiä julkaistuja, jotka tasoittavat tietä nykyisille ja nykyisille suosituille kehyksille. Tänään kolme parasta olisi (mielestämme) Zend Framework, Symfony ja tietysti Laravel. Vaikka jokainen näistä viitekehyksestä perustui samanlaisiin periaatteisiin ja on suunnattu ratkaisemaan (periaatteessa) samoja yhteisiä ongelmia, niiden tärkeimmät erot ovat niiden toteutukset. Heillä jokaisella on omat omituisuutensa ongelmien ratkaisemisessa. Kun katsot kunkin niistä tuottamaa koodia, huomaat, että ne erottaa toisistaan ​​melko kiinteä viiva. Nöyrä mielestämme Laravel-kehys on paras.

Lisätietoja Ero Laravelin ja CodeIgniterin välillä

Kuinka ladata ja asentaa Laravel Composerilla

HUOMAUTUS Oletuksena on, että sinulla on jo kopio PHP:stä asennettuna paikalliseen järjestelmääsi. Jos ei, voit lukea kuinka se asennetaan 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ä:

Huomautuksia Katso Laravelin dokumentaatiosta laajemmat ohjeet Laravelin asettamisesta täältä.

Näet sen lataavan ja kääntävän composer.phar-skriptin, jota käytämme Laravelin asentamiseen. Vaikka on olemassa lukuisia tapoja luoda uusi Laravel-sovellus, teemme sen Laravelin säveltäjäkäsikirjoituksen avulla. Asenna tämä komentosarja suorittamalla:

composer global require laravel/installer

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

Tämä lataa ja asentaa kaikki kehystiedostot itse sekä kaikki sen tarvitsemat riippuvuudet. Paketit tallennetaan toimittajahakemistoon. 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 paketit, joita Laravel tarvitsee toimiakseen. Se voi kestää muutaman minuutin, joten ole kärsivällinen. Kun se on valmis, suorita ls -al -komento nähdäksesi, mitä asennettiin.

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

• sovellus/ : Tämä on lähdekansio, jossa sovelluskoodimme sijaitsee. Kaikki ohjaimet, käytännöt ja mallit ovat tässä kansiossa
• bootstrap/ : Sisältää sovelluksen käynnistysohjelman ja muutaman luokkakarttatiedoston
• config/ : Sisältää sovelluksen määritystiedostoja. Näitä ei yleensä muokata suoraan, vaan ne perustuvat sovelluksen juuren .env (environment) -tiedostoon määritettyihin arvoihin.
• tietokanta/ : Sisältää tietokantatiedostot, mukaan lukien siirrot, siemenet ja testitehtaat
• julkinen/ : Julkisesti saatavilla oleva kansio, joka sisältää kootut resurssit ja tietysti index.php-tiedoston
• resurssit/ : Sisältää käyttöliittymän resursseja, kuten JavaScript-tiedostoja, kielitiedostoja, CSS/SASS-tiedostoja ja kaikki sovelluksessa käytetyt mallit (kutsutaan blade-malleiksi).
• reitit/ : Kaikki sovelluksen reitit ovat sisällä täällä. Reittejä on muutamia erilaisia, mutta yksi, johon keskitymme, on web.php-tiedosto
• varastointi/ : Kaikki sovelluksen käyttämät väliaikaiset välimuistitiedostot, istuntotiedostot, käännetyt näkymäskriptit ja lokitiedostot
• testit/: Sisältää sovelluksen testitiedostoja, kuten yksikkötestejä ja toimintatestejä.
• myyjä/: Kaikki säveltäjän mukana asennetut riippuvuuspaketit

Nyt sitten rakennetaan loput sovelluksesta ja ajetaan se erityisellä artesaanikomennolla (säästämme itseämme Web-palvelimen, kuten Apachen tai nginxin, asentamisesta ja määrittämisestä). .env-tiedosto sisältää kaikki määritysarvot, joita /config-hakemiston tiedostot käyttävät sovelluksen määrittämiseen. Sen sisällä huomaat, että sovelluksen sisäosien käyttämien eri parametrien konfiguraatioarvot.

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 kirjoitus, mikä tarkoittaa, että käyttäjä voi kirjoittaa vain tiedostoja ja tarkastella lataamiensa tiedostojen luetteloa. Tämä sovellus on erittäin yksinkertainen, mutta sen pitäisi toimia hyvänä käytäntönä, jonka avulla voit alkaa rakentaa Laravel-taitojasi ja -tietojasi. Huomaa, että lyhyyden vuoksi olen jättänyt pois tietokannan mallintamisen, siirrot ja todennuksen, mutta tosielämän sovelluksissa nämä ovat muita asioita, joita sinun kannattaa harkita.

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

• A reitti jonka avulla ulkomaailma (internet) voi käyttää sovellusta sekä määrittää päätepisteen, joka osoittaa, missä ladatun tiedoston tallentamisen logiikka sijaitsee
• A ohjain joka käsittelee pyynnön vastausvirtaan
• A sapluuna jota käytetään näyttämään luettelo aiemmin ladatuista tiedostoista ja itse latauslomake
• A pyyntö joita rekisterinpitäjä käyttää verkkolomakkeesta lähetettyjen tietojen vahvistamiseen

Mikä on reitti?

Laravelin reitti on periaatteessa URI:n määrittelemä päätepiste, joka toimii "osoittimena" johonkin sovelluksen tarjoamaan toimintoon. Yleisimmin reitti osoittaa yksinkertaisesti ohjaimessa olevaan menetelmään ja myös sanelee, mitkä HTTP-menetelmät voivat osua kyseiseen URI:hen. Reitti ei myöskään aina tarkoita ohjainmenetelmää; se voisi vain siirtää sovelluksen suorittamisen myös määritellylle sulkemis- tai anonyymille toiminnolle.

Miksi käyttää Routea?

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

• web.php Julkiset "selainpohjaiset" reitit. Nämä ovat yleisimpiä, ja verkkoselain iskee niihin. Ne kulkevat web-väliohjelmistoryhmän läpi ja sisältävät myös tilat csrf-suojaus (joka auttaa puolustautumaan lomakepohjaisilta haitallisilta hyökkäyksiltä ja hakkeroilta) ja sisältävät yleensä jonkin verran "tilaa" (tarkoitan tällä, että ne käyttävät istuntoja)
• api.php Reitit, jotka vastaavat API-ryhmää ja joissa on siten API-väliohjelmisto oletuksena käytössä. Nämä reitit ovat tilattomia, eikä niissä ole istuntoja tai ristiinpyyntömuistia (yksi pyyntö ei jaa tietoja tai muistia minkään muun pyynnön kanssa – jokainen on itsekapseloitu).
• console.php Nämä reitit vastaavat mukautettuja käsityöläiskäskyjä, jotka olet luonut sovelluksellesi
• channels.php Rekisteröi tapahtumien lähetysreitit

Avaintiedosto, jota on käsiteltävä tällä hetkellä, on selainkohtainen, web.php . Oletusarvoisesti on jo määritetty yksi reitti, johon osut oikealla navigoidessasi sovelluksesi verkkojuureen (verkkojuuri on julkisessa hakemistossa). Tarvitsemme kolmea eri reittiä, jotta lataussovelluksemme toimisi:

• /upload Tämä on pääsivun URI, joka näyttää verkkolomakkeemme tiedostojen lataamista varten.
• /process Tämä on paikka, jossa /upload URI:ssa oleva lomake lähettää lomakkeella lähetetyt tiedot (lomakkeen "toiminto")
• /list Tämä listaa kaikki sivustolle ladatut tiedostot

huomata /list-päätepistettä ei ehkä tarvita, jos halusimme laittaa kaikki logiikka latauslomakkeen ja tiedostoluettelon näyttämiseksi yhdelle sivulle, mutta pidimme ne toistaiseksi erillään lisätäksemme hieman enemmän 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-kehyksen opetusohjelmassa luetellaan jokaiselle halutulle reitille se erikseen reittitiedostoon web.php käyttämällä yhtä käytettävissä olevista HTTP-kohtaisista pyyntömenetelmistä (get(), post(), put() , delete(), patch() tai option() ). Tarkista kunkin näistä erittely tätä ulos. Nämä menetelmät määrittelevät, mitkä HTTP-verbit saavat käyttää tiettyä reittiä. Jos tarvitset reitin voidaksesi hyväksyä useamman kuin yhden HTTP-verbin (mikä voi olla tilanne, jos käytät yhtä sivua sekä alkutietojen näyttämiseen että lähetettyjen lomaketietojen lähettämiseen), voit käyttää Route::any( ) menetelmä.

Toinen argumentti sekä Route::get()- että Route::post()-metodeille (ja muille Reitin julkisivussa oleville HTTP-verbiin liittyville menetelmille) on tietyn ohjaimen ja sen sisällä olevan menetelmän nimi. ohjain, joka suoritetaan osuessaan reitin päätepisteeseen sallitulla HTTP-pyynnöllä (GET, POST, PATCH jne.) Käytämme UploadControlleria kaikille kolmelle reitille ja olemme määrittäneet ne seuraavasti:

Viimeinen menetelmä, jota kutsumme kullakin reitillä, on sen name()-funktio, joka hyväksyy yhden merkkijonon argumenttina ja jota käytetään enemmän tai vähemmän "merkitsemään" tietty reitti helposti muistettavalla nimellä (meissä tapauksissa lataa, käsittele ja luetteloi). Ymmärrän, että ei vaikuta kovin hyvältä ominaisuudesta antaa jokaiselle reitille oma nimi, kun URL-osoite on nimetty täsmälleen samalla tavalla, mutta se on todella hyödyllistä, kun sinulla on tietty reitti, kuten /users/profile/dashboard/config, joka olisi helpompi muistaa nimellä profile-admin tai user-config.

Huomautus julkisivuista:

• Julkisivut tarjoavat "staattisen" käyttöliittymän luokille, jotka ovat saatavilla sovelluksen palvelusäiliössä."
• 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ä olevat reittimääritykset tässä Laravel-kehysopetusohjelmassa, käytämme Reitin julkisivua sen sijaan, että luomme manuaalisesti uuden Illuminate/Routing/Router-objektin ja kutsumme vastaavia menetelmiä kyseiselle objektille. Se on vain pikakuvake, joka säästää kirjoittamisen. Julkisivuja käytetään paljon Laravel-kehyksessä – niihin voi ja kannattaa tutustua paremmin. Julkisivujen asiakirjat löytyvät 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 paljain käsin määritelmä ja se on myös minkä tahansa ohjaimen vähimmäisvaatimus. Se, mitä se tekee näiden kahden asian välillä, katsotaan yleensä ohjaimen "toimintoksi" (tai "reitin toteutukseksi"). Se toimii toisena sisääntulopisteenä sovellukseen (ensimmäinen on pyyntö) asiakkaalle, joka lähettää pyynnön hyötykuorman (johon pääsemme seuraavaksi) sovellukselle odottaen jonkinlaista vastausta (muodossa onnistumissivu, uudelleenohjaus, virhesivu tai mikä tahansa muu HTTP-vastaus).

Ohjain tekee (periaatteessa) saman kuin reitinmäärittely, jonka anonyymi toiminto on asetettu "toiminnoksi", kun reitti osuu. Erona on se, että ohjain kestää hyvin huolenaiheiden erottelun, kun taas reitti on määritetty todellisen URL-määritelmän mukaisesti, mikä tarkoittaa periaatteessa, että yhdistämme reitille osoitetun URI:n reitin toteutukseen tai koodiin, joka suoritetaan, kun kyseinen reitti on osuma.

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 routes/web.php:n sisällä, mutta sen toteutus on /app/Http/Controllers/HelloWorldController-luokan sisällä.

//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 näyttää paljon enemmän työltä (mitä se ei ole – vain vähän enemmän koodia riittää), katso hyödyt, joita saamme laittamalla toimintalogiikkamme annetulle "hello-world" -reitille ohjaimen sisään. reitin määrittelystä takaisinsoittofunktiona:

1. Logiikkamme on selkeästi erotettu omaan luokkaansa (huolenaiheiden erottelu)
2. Ohjaimemme on asetettu laajennettavaksi myöhemmin, jos tarvitsemme siihen lisäominaisuuksia… Sano, että ehkä halusimme lisätä "hyvästi maailma" -ominaisuuden... Tässä tapauksessa nimeämme ohjaimen uudelleen yleisemmäksi "HelloControlleriksi" ja määritämme sitten kaksi erillistä menetelmää, Hei() ja Hyvästi(). Meidän olisi myös määritettävä kaksi erillistä reittiä, jotka kartoittavat /Hei ja / Hyvästi URI-osoitteet sopivaan menetelmään ohjaimessa. Tämä on toivottavaa verrattuna reittitiedoston lihotukseen, jossa kunkin reitin toteutus on määritelty takaisinsoittofunktioiksi.
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 määrittämäsi reitit sovelluksen sisällä on määritetty käyttämällä ohjainkohtaisia ​​kartoituksia (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 "UploadController"-nimiselle ohjaimelle ohjaimen päähakemistoon osoitteessa /app/Http/Controllers/UploadController.php. Avaa tiedosto ja katso se. Se on hyvin yksinkertaista, koska se on vain ohjaimen tynkäversio, jossa on oikea nimiavaruuden polku ja vaaditut luokat, joista se ulottuu.

Pyynnön luominen

Ennen kuin jatkamme tässä PHP Laravel -opetusohjelmassa ja teemme muutamia muutoksia UploadControllerin luomaan tyngään, mielestäni on järkevämpää luoda pyyntöluokka ensin. Tämä johtuu siitä, että pyyntöä käsittelevän controller-metodin on kirjoitettava vihje pyyntöobjektille allekirjoituksessaan, jolloin se voi automaattisesti vahvistaa saapuvat lomaketiedot (määritelty rule()-metodissa. Siitä lisää myöhemmin…) Käytetään nyt artisan-komento uudelleen luomaan pyyntömme tynkä:

php artisan make:request UploadFileRequest

Tämä komento luo tiedoston nimeltä UploadFileRequest sisällä app/Http/Requests/UploadFileRequest. Avaa tynkä ja kurkista… Se on hyvin yksinkertainen, sillä se sisältää vain kaksi menetelmää, Authorize() ja säännöt.

Validointilogiikan luominen

Muokkaamme pyynnön tynkä vastaamaan sovelluksemme tarpeita. Muokkaa tiedostoa niin, että se näyttää tältä:

<?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 paljon muutoksia, mutta huomaa, että authorize()-metodi palauttaa nyt true eikä false. Tämä menetelmä päättää, sallitaanko pyynnön siirtyminen sovellukseen vai ei. Jos arvoksi on asetettu epätosi, se estää pyyntöä saapumasta järjestelmään (joka normaalisti olisi ohjaimen menetelmä). Tämä olisi erittäin kätevä paikka tehdä käyttäjän valtuutustarkistuksia tai mikä tahansa muu logiikka, joka voi päättää, voidaanko pyyntö siirtää eteenpäin ohjaimelle. Toistaiseksi palaamme tähän vain totta, jotta kaikki ja kaikki voivat käyttää pyyntöä.

Toinen menetelmä, rules() on se, jossa kaikki taika tulee voimaan validoinnissa. 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ässä olevasta lomakkeesta. FileName-parametrin tulee olla 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ä tiedoston nimen on oltava merkkijono lisäämällä putkimerkki (|) ja sana "merkkijono". Rajoitukset on aina rajattu putkilla, jolloin voit määrittää lisäkriteerit annetulle kentälle yhdellä rivillä! Mikä voima!

Toinen parametri, userFile, on varsinainen tiedosto, jonka käyttäjä lataa verkkosivun lomakkeesta. UserFile vaaditaan myös ja täytyy olla tiedosto. Huomautus: Jos odotimme ladatun tiedoston olevan kuva, käyttäisimme sen sijaan kuvarajoitusta, joka rajoittaisi yhdeksi suosituista kuvatyypeistä hyväksyttyjä tiedostotyyppejä (jpeg, png, bmp, gif tai svg). Koska haluamme sallia käyttäjän ladata minkä tahansa tyyppisiä tiedostoja, pysymme vain tiedoston vahvistusrajoituksessa.

Siinä on kaikki, mitä pyyntöobjektissa on. Sen päätehtävänä on yksinkertaisesti pitää hallussaan hyväksyttävät kriteerit (rajoitukset), jotka lomakkeen runkoparametrien on täytettävä voidakseen edetä syvemmälle sovellukseen. Toinen huomioitava 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 nimi vastaa pyyntöobjektin sisällä olevaa nimeä).

Saatat kysyä: tämä varmasti määrittää ominaisuudet, mitä lomakepyynnön tulee sisältää, mutta missä näiden rajoitusten varsinainen tarkistus tehdään? Palataan asiaan 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 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
   }
}

Joten se on melko yksinkertainen tapa tallentaa ladatut tiedostot levylle. Tässä on erittely yllä olevasta upload()-menetelmästä:

• Kirjoita pyyntöluokka ohjainmenetelmään, joka suorittaa liha ja perunat -toiminnon, jotta voimme tarkistaa saapuvat tiedot automaattisesti
• Ota tiedosto pois (nyt validoidusta) pyyntöobjektista controller-metodin sisällä (tässä tapauksessa olemme antaneet sille nimen upload(), mutta se olisi voitu nimetä myös standardoidulla nimellä, kuten store()).
• Ota tiedostonimi pois 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.
• Palauta JSON-vastaus, joka osoittaa, että pyyntö onnistui

Blade-malli

Tämän palapelin viimeinen tärkeä osa on blade-malli, joka sisältää kaikki HTML-, CSS- ja JavaScript-koodit yksinkertaista sovellusta varten. Tässä on koodi – selitämme sen myöhemmin.

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

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

Tämä on hyvin tyypillinen esimerkki blade-tiedostosta, joka sisältää HTML-lomakkeen ja javascriptin/jQueryn asynkronisten toimintojen lisäämiseksi (jotta sivu ei päivity). On perus -tunniste, jossa ei ole method-attribuuttia (jonka selitän vain sekunnissa) ja uteliaalla action-attribuutilla, jonka arvo on {{route('file.upload')}}. Terässä tämä tunnetaan nimellä a Direktiivi. Direktiivi on vain funktion kuvitteellinen nimi – ne ovat korttimalleille ominaisia ​​toimintoja, jotka suorittavat erilaisia ​​toimintoja, jotka ovat yhteisiä verkkosivujen ja verkkosovellusten rakentamisessa. Asiakirjoista saat paremman käsityksen kaikesta hienosta paskasta, jota blade voi tehdä täältä. Yllä olevassa tapauksessa käytämme reittiohjetta URL-osoitteen luomiseen lomakkeen lähettämistä varten.

Muista, että määritimme reitit aiemmin sovelluksessa web.php-tiedoston sisällä ja määritimme jokaiselle helposti muistettavan nimen. {{route()}}-käsky hyväksyy reitin nimen, etsii sen sisäisesti välimuistissa olevasta reittiluettelosta ja luo täydellisen URL-osoitteen 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 sovelluksemme /process-URL-osoitteeseen, joka on määritelty POST reittiä.

Seuraava outo asia, jonka olet ehkä huomannut, on @csrf-tunniste heti avauslomakkeen tagin alla. Bladessa tämä tagi luo lomakkeeseen _token-parametrin, joka tarkistetaan sovelluksen sisällä ennen kuin lomaketietojen käsittely sallitaan. Tämä varmistaa, että lomakkeen sisältämät tiedot ovat kelvollista alkuperää ja estää sivustojen väliset pyyntöväärennöshyökkäykset. Lisätietoja tästä on osoitteessa docs.

Tämän jälkeen määrittelemme lomakkeemme normaaliksi, mutta huomioi, että lomakeparametreidemme userFile ja fileName nimet ovat täsmälleen sama kuten on määritelty pyyntöobjektissamme. Jos unohdamme sisällyttää syötteen tietylle parametrille, joka määritettiin pyyntöobjektissa (tai kirjoitimme sen väärin), pyyntö epäonnistuu ja palautettaisiin virhe, joka estäisi alkuperäistä lomakepyyntöä osumasta ohjainmenetelmään, joka sijaitsee osoitteessa UploadController@ käsitellä asiaa .

Mene eteenpäin ja 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

Otetaan askel taaksepäin ja katsotaan, mitä olemme tehneet tässä Laravel-opetusohjelmassa.

Tämä kaavio esittää sovelluksen sellaisena kuin se on tällä hetkellä (ei sisällä korkean tason yksityiskohtia):

Muista, että tämän Laravel-opetusohjelman alussa luomallamme pyyntöobjektilla tulisi olla samat parametrit, jotka on määritelty sen sääntömenetelmässä kuin korttimallin lomakkeessa (jos et, lue uudelleen osio "Validointilogiikan luominen"). . Käyttäjä syöttää lomakkeen web-sivulle, joka hahmonnetaan blade-mallimoottorin kautta (tämä prosessi on tietysti automaattiohjattu, joten meidän ei tarvitse edes ajatella sitä) ja lähettää lomakkeen. Mallin alareunassa oleva jQuery-koodi pysäyttää oletuslähetyksen (joka ohjaa automaattisesti erilliselle sivulle), luo ajax-pyynnön, lataa pyynnön lomakkeen tiedoineen ja lataa tiedoston ja lähettää koko jutun ensimmäiseen kerrokseen. sovellus: pyyntö.

Pyyntöobjekti täytetään yhdistämällä säännöt()-metodin sisällä olevat parametrit lähetettyihin lomakeparametreihin, minkä jälkeen se vahvistaa tiedot kunkin määritetyn säännön mukaisesti. Jos kaikki säännöt täyttyvät, pyyntö välitetään mille tahansa ohjainmenetelmälle, joka vastaa reittitiedostossa web.php määritettyjä arvoja. Tässä tapauksessa UploadControllerin process()-menetelmä tekee työn. Kun osumme ohjaimeen, tiedämme jo, että pyyntö läpäisi vahvistuksen, joten meidän ei tarvitse testata uudelleen, onko annettu tiedostonimi itse asiassa merkkijono vai sisältääkö userFile-parametri todella jonkin tyyppisen tiedoston… Voimme jatkaa näin normaali.

Ohjausmenetelmä nappaa sitten validoidut parametrit pyyntöobjektista, luo täyden tiedostonimen ketjuttamalla välitetyn fileName-parametrin userFilen alkuperäiseen tunnisteeseen, tallentaa tiedoston sovelluksemme hakemistoon ja palauttaa sitten yksinkertaisen JSON-koodatun vastauksen, joka vahvistaa pyynnön onnistumisen. Vastauksen vastaanottaa jQuery-logiikka, joka suorittaa muutamia käyttöliittymään liittyviä tehtäviä, kuten näyttää onnistumis- (tai virhe-)viestin 5 sekunniksi, sitten piilottaa sen sekä tyhjentää aiemmat lomakemerkinnät… tämä on, jotta käyttäjä tietää varmistaakseen, että pyyntö onnistui, ja voivat halutessaan ladata toisen tiedoston.

Huomaa myös yllä olevasta kaaviosta, missä raja on vedetty asiakkaan ja palvelimen välille. Tämä käsite on ehdottoman tärkeä ymmärtääksesi, ja se auttaa sinua ratkaisemaan ongelmia ja ongelmia, joita sinulla saattaa olla tulevaisuudessa, kun jongleeraat esimerkiksi useita asynkronisia pyyntöjä, joita voi esiintyä milloin tahansa. Erottelu on aivan pyyntöobjektin rajalla. Itse pyyntöobjektia voidaan pitää "yhdyskäytävänä" muuhun sovellukseen… Se suorittaa verkkoselaimesta välitettävien lomakearvojen alkuperäisen vahvistuksen ja rekisteröinnin. Jos ne katsotaan kelvollisiksi, se jatkuu ohjaimelle. Kaikki ennen sitä on käyttöliittymässä ("asiakas" tarkoittaa kirjaimellisesti "käyttäjän tietokoneessa"). Vastaus palautetaan sovelluksesta takaisin asiakaspuolelle, jossa jQuery-koodimme kuuntelee kärsivällisesti sen saapumista ja suorittaa muutaman yksinkertaisen käyttöliittymätehtävän vastaanotettuaan sen.

Olemme käsitelleet yli 90 tärkeää usein kysyttyä Laraveliin ja PHP:hen liittyvät haastattelukysymykset niin uusille kuin kokeneillekin hakijoille oikean työn saamiseksi.