Laravel oktatóanyag kezdőknek

Mi az a Laravel?

Laravel egy nyílt forráskódú web MVC keretrendszer PHP-hez. A Laravel egy robusztus keretrendszer, amely a PHP webalkalmazások egyszerű fejlesztését teszi lehetővé, olyan funkciókkal, mint a moduláris csomagolórendszer dedikált függőségi kezelővel, hozzáférés a relációs adatbázisokhoz és egyéb alkalmazások telepítéséhez és karbantartásához.

A Laravelt Taylor Otwell készítette. A 2011. júniusi kezdeti kiadás óta (1. verzió) folyamatosan egyre népszerűbbé vált a webfejlesztő iparág PHP-keretrendszerében. Ennek a népszerűségnek a nagy része a készlethez tartozó számos, fejlesztők számára elsőrendű funkciónak tudható be.

Miért Laravel?

2000 körül a legtöbb PHP kódok eljárási jellegű volt, és „szkriptek” formájában találhatók meg, amelyekben a spagetti kód kusza összevisszasága volt. Még a legegyszerűbb oldalakon sem volt semmi az aggodalmak szétválasztása, és így egy alkalmazás gyorsan karbantartási rémálommá nőtte ki magát. A világnak valami jobbra volt szüksége… Írja be a PHP 5-ös verzióját és számos PHP-keretrendszert, hogy megpróbáljon néhány nagyon szükséges felbontást és jobb megoldásokat hozni a különféle webalkalmazásokkal kapcsolatos problémákra.

Azóta sok olyan keretrendszert láthattunk, amely megnyitja az utat a ma létező és használt népszerű keretrendszerek előtt. Ma az első három (szerintünk) a Zend Framework, a Symfony és természetesen a Laravel lenne. Bár ezek a keretrendszerek mindegyike hasonló elvekre épült, és (alapvetően) ugyanazon közös problémák megoldására irányul, a legfontosabb különbségek a megvalósításukban rejlenek. Mindegyiküknek megvan a maga furcsasága a problémák megoldásával kapcsolatban. Ha megnézi mindegyik által előállított kódot, látni fogja, hogy egy elég szilárd vonal választja el őket egymástól. Szerény véleményünk szerint a Laravel keretrendszer a legjobb.

Tudjon meg többet A Laravel és a CodeIgniter közötti különbség

A Laravel letöltése és telepítése a Composer segítségével

JEGYZET Feltételezzük, hogy a PHP egy példánya már telepítve van a helyi rendszerünkön. Ha nem, akkor elolvashatja a telepítés módját itt

A Composer egyszerre csomag- és függőségi kezelő. A telepítéshez nyisson meg egy terminált és egy CD-t egy új könyvtárba. Futtassa ezt a parancsot:

curl -Ss getcomposer.org/installer | php

A parancs eredménye így fog kinézni:

Megjegyzések A Laravel beállításával kapcsolatos részletesebb utasításokért tekintse meg a Laravel dokumentációját itt .

Látni fogja, hogy letölti és lefordítja a composer.phar szkriptet, amelyet a Laravel telepítéséhez használunk. Bár számos módja van egy új Laravel alkalmazás beállításának, ezt a Laravel zeneszerzői szkripten keresztül fogjuk megtenni. A szkript telepítéséhez futtassa:

composer global require laravel/installer

Ami valahogy így fog kinézni:

Ezzel letölti és telepíti magát az összes keretfájlt, valamint az összes szükséges függőséget. A csomagok a szállítói könyvtárba kerülnek mentésre. Miután letöltötte és telepítette, olyan egyszerű, mint a következő parancs kiadása:

laravel new uploadApp

A következő kimenethez hasonlót fog látni:

A Composer telepíti az összes csomagot, amelyre a Laravelnek szüksége van a futáshoz. Eltarthat néhány percig, ezért légy türelmes. Miután befejezte, futtassa az ls -al parancsot, hogy megnézze, mi lett telepítve.

Íme egy rövid bontás a könyvtárakról egy általános Laravel alkalmazásban:

app/ : Ez a forrásmappa, ahol az alkalmazás kódja él. Minden vezérlő, házirend és modell ebben a mappában található
bootstrap/ : Tartalmazza az alkalmazás indító szkriptjét és néhány osztálytérkép fájlt
config/ : Tárolja az alkalmazás konfigurációs fájljait. Ezeket általában nem módosítják közvetlenül, hanem az alkalmazás gyökerében található .env (environment) fájlban beállított értékekre hagyatkoznak.
adatbázis/ : Az adatbázis-fájlokat tartalmazza, beleértve a migrációkat, a magokat és a tesztgyárakat
nyilvános/ : Nyilvánosan elérhető mappa, amely lefordított eszközöket és természetesen index.php fájlt tartalmaz
erőforrások/ : Olyan front-end eszközöket tartalmaz, mint a javascript-fájlok, nyelvi fájlok, CSS/SASS-fájlok és az alkalmazásban használt összes sablon (úgynevezett blade-sablonok).
útvonalak/ : Az alkalmazásban szereplő összes útvonal itt található. Van néhány különböző „hatóköre” az útvonalaknak, de az egyikre fogunk összpontosítani, az a web.php fájl
tárolás/ : Az alkalmazás által használt összes ideiglenes gyorsítótár-fájl, munkamenet-fájlok, lefordított nézeti szkriptek és naplófájlok
tesztek/ : Tesztfájlokat tartalmaz az alkalmazáshoz, például egységteszteket és funkcionális teszteket.
eladó/ : Minden függőségi csomag telepítve a zeneszerzővel

Most pedig készítsük el az alkalmazás többi részét, és futtassuk azt egy speciális kézműves paranccsal (hogy megkíméljük magunkat az olyan webszerverek telepítésétől és konfigurálásától, mint az Apache vagy az nginx). Az .env fájl tartalmazza az összes konfigurációs értéket, amelyet a /config könyvtárban lévő fájlok az alkalmazás konfigurálásához használnak. Belül észreveheti, hogy az alkalmazás belső részei által használt különféle paraméterek konfigurációs értéke.

Alkalmazástervezés: Követelményeink gyors lefutása

Ebben az online Laravel oktatóanyagban egy nagyon egyszerű alkalmazást fogunk készíteni, amely csak két dolgot fog megtenni:

webes űrlapról történő fájlfeltöltések kezelése
a korábban feltöltött fájlok megjelenítése egy másik oldalon.

Ennél a projektnél az alkalmazásunk csak írható lesz, ami azt jelenti, hogy a felhasználó csak fájlokat írhat, és megtekintheti a feltöltött fájlok listáját. Ez az alkalmazás rendkívül alapvető, de jó gyakorlatként szolgálhat a Laravel-készségek és ismeretek fejlesztéséhez. Ne feledje, hogy a rövidség kedvéért kizártam az adatbázis-modellezést, az áttelepítést és a hitelesítést, de a valós alkalmazásoknál ezek további szempontok, amelyeket érdemes figyelembe venni.

Itt található azoknak az összetevőknek a listája, amelyekre szükségünk lesz ahhoz, hogy az alkalmazás a várt módon működjön:

A útvonal amely lehetővé teszi a külvilág (internet) számára az alkalmazás használatát, valamint megadja azt a végpontot, amely a feltöltött fájl mentési logikájának helyére mutat.
A ellenőr amely kezeli a válaszfolyamatot
A sablon amely a korábban feltöltött fájlok listájának és magának a tényleges feltöltési űrlapnak a megjelenítésére szolgál
A kérni amelyet az adatkezelő a webes űrlapról beküldött adatok érvényesítésére fog használni

Mi az az útvonal?

A Laravel útvonala alapvetően egy URI által meghatározott végpont, amely „mutatóként” működik az alkalmazás által kínált egyes funkciókra. Leggyakrabban az útvonal egyszerűen egy metódusra mutat a vezérlőn, és azt is megszabja, hogy mely HTTP-metódusok érhetik el ezt az URI-t. Az útvonal nem mindig jelent vezérlő módszert sem; csak átadhatja az alkalmazás végrehajtását egy meghatározott bezárásnak vagy névtelen függvénynek is.

Miért használja az Útvonalat?

Az útvonalak a projekt gyökérkönyvtárában található /routes mappa fájljaiban tárolódnak. Alapértelmezés szerint néhány különböző fájl felel meg az alkalmazás különböző „oldalainak” (az „oldalak” a hatszögletű architektúra módszertanából származnak). Ezek a következők:

web.php A „böngésző” alapú útvonalak a nyilvánosság előtt. Ezek a leggyakoribbak, és ezeket éri el a webböngésző. A webes köztesszoftver-csoporton keresztül futnak, és tartalmaznak lehetőségeket is csrf védelem (ami segít védekezni az űrlap alapú rosszindulatú támadások és feltörések ellen), és általában tartalmaz bizonyos fokú „állapotot” (ez alatt azt értem, hogy munkameneteket használnak)
api.php Olyan útvonalak, amelyek egy API-csoportnak felelnek meg, és így alapértelmezés szerint engedélyezve vannak az API köztes szoftverrel. Ezek az útvonalak állapot nélküliek, és nem rendelkeznek munkamenetekkel vagy keresztkérések memóriájával (egy kérés nem oszt meg adatokat vagy memóriát egyetlen másik kéréssel sem – mindegyik önállóan záródik).
console.php Ezek az útvonalak az alkalmazásához létrehozott egyéni kézműves parancsoknak felelnek meg
channels.php Regisztrálja az események közvetítésének útvonalait

A kulcsfájl, amellyel jelenleg foglalkozni kell, a böngésző-specifikus, a web.php. Már van egy alapértelmezés szerint definiált útvonal, amely az alkalmazás webgyökéréhez való navigáláskor (a webgyökér a nyilvános könyvtárban található) közvetlenül azt az útvonalat érinti. Három különböző útvonalra lesz szükségünk a feltöltési alkalmazásunk működéséhez:

/upload Ez annak a főoldalnak az URI-je, amelyen megjelenik a fájlok feltöltésére szolgáló webes űrlapunk.
/process Ez lesz az a hely, ahol a /upload URI-n található űrlap elküldi az űrlapon elküldött adatait (az űrlap művelete)
/list Ez kilistázza az oldalra feltöltött összes fájlt

megjegyezni Előfordulhat, hogy a /list végpontra nem lesz szükség, ha a feltöltési űrlap és a fájlok listájának megjelenítéséhez szükséges összes logikát egyetlen oldalon szeretnénk elhelyezni, azonban egyelőre külön tartottuk őket, hogy egy kicsit többet fűzzünk a tárgyhoz. .

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

Ebben a Laravel keretrendszer oktatóanyagában minden egyes kívánt útvonalhoz kifejezetten felsoroljuk azokat a web.php útvonalfájlban az elérhető HTTP-specifikus kérési metódusok egyikével (get(), post(), put() , delete(), patch() vagy options() ). Ezek mindegyikének bontását tekintse meg ezt ki. Ezek a módszerek az, hogy meghatározzák, mely HTTP igék férhetnek hozzá az adott útvonalhoz. Ha egy útvonalra van szüksége ahhoz, hogy egynél több HTTP igét tudjon elfogadni (ez lehet a helyzet, ha egyetlen oldalt használ a kezdeti adatok megjelenítésére és a beküldött űrlapadatok közzétételére), használhatja az Route::any( ) módszerrel.

A Route::get() és Route::post() metódusok (és az Útvonal homlokzatán lévő többi HTTP-igével kapcsolatos metódus) második argumentuma egy adott vezérlő és azon belül található metódus neve. vezérlő, amely akkor kerül végrehajtásra, ha az útvonal végpontját eléri az engedélyezett HTTP kéréssel (GET, POST, PATCH stb.) Mindhárom útvonalhoz az UploadControllert használjuk, és a következő módon határoztuk meg őket:

Az utolsó metódus, amelyet minden útvonalon meghívunk, a name() függvény, amely egyetlen karakterláncot fogad el argumentumként, és egy adott útvonal többé-kevésbé könnyen megjegyezhető névvel való „felcímkézésére” szolgál (esetünkben, feltöltés, feldolgozás és listázás). Tudom, hogy nem tűnik olyan nagyszerűnek, hogy minden útvonalnak saját nevet adjon, ha az URL-cím pontosan ugyanaz, de nagyon hasznos, ha van egy adott útvonal, például /users/profile/dashboard/config, amelyet könnyebb lenne megjegyezni profil-admin vagy user-config néven.

Megjegyzés a homlokzatokról:

A homlokzatok „statikus” felületet biztosítanak az alkalmazás szolgáltatástárolójában elérhető osztályoknak.”
Rövid, emlékezetes szintaxist biztosítanak, amely lehetővé teszi a Laravel szolgáltatásainak használatát anélkül, hogy megjegyezné a hosszú osztályneveket, amelyeket manuálisan kell beadni vagy konfigurálni.

A fenti útvonaldefiníciók ebben a Laravel keretrendszer oktatóanyagában az Útvonal homlokzatot használjuk ahelyett, hogy manuálisan létrehoznánk egy új Illuminate/Routing/Router objektumot, és meghívnánk a megfelelő metódusokat az adott objektumon. Ez csak egy gyorsbillentyű, amely megtakarítja a gépelést. A Laravel keretrendszerben a homlokzatokat nagymértékben használják – meg lehet és érdemes is megismerkedni velük. A Homlokzatok dokumentumai megtalálhatók itt .

Mi az a vezérlő?

A vezérlő a „C” az „MVC” (Model-View-Controller) architektúrában, amelyen a Laravel alapul. A vezérlő feladata az alábbi egyszerű definícióra vezethető vissza: Megkapja a kérést az ügyféltől, és választ küld az ügyfélnek. Ez a csupasz definíció, és egyben minden adott vezérlő minimális követelménye is. Amit a két dolog között tesz, az általában a vezérlő „műveletének” (vagy az „útvonal megvalósításának”) tekintendő. Ez az alkalmazás második belépési pontjaként működik (az első a kérés) az ügyfél felé, aki elküldi a kérés hasznos terhét (amelyhez legközelebb fogunk eljutni) az alkalmazáshoz, várva valamilyen választ (a kérés formájában). sikeroldal, átirányítás, hibaoldal vagy bármilyen más HTTP-válasz).

A vezérlő (alapvetően) ugyanazt csinálja, mint egy útvonal-definíció, amelynek anonim funkciója „műveletként” van beállítva, amikor az útvonalat eltalálják. A különbség az, hogy a vezérlő jól tartja magát az aggodalmak szétválasztásához, míg az útvonal a tényleges url definíció szerint van definiálva, ami lényegében azt jelenti, hogy összekapcsoljuk az útvonalhoz rendelt URI-t az útvonal megvalósításával vagy a kóddal, amely akkor fut le, amikor az útvonal találat.

Például a következő két kódrészlet ugyanazt fogja elérni:

1. példa: Útvonal meghatározása és megvalósítása egyetlen metódushíváson belül (a web.php routes fájlban)

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

2. példa: Az útvonal definíciója a routes/web.php fájlban található, de megvalósítása a /app/Http/Controllers/HelloWorldController osztályon belül található

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

Bár a Laravel 2. példája sokkal több munkának tűnik (ami nem – csak egy kicsivel több kód az egész), nézzük meg, milyen előnyök származnak abból, ha a cselekvési logikánkat az adott „hello-world” útvonalon egy vezérlőbe helyezzük. az útvonal meghatározásával visszahívási függvényként:

Logikánk tisztán szét van osztva a saját osztályába (a gondok szétválasztása)
A vezérlőnket a későbbiekben bővítjük, ha további képességeket kell hozzáadnunk hozzá… Tegyük fel, hogy egy „viszlát-világ” funkciót akartunk hozzáadni… Ebben az esetben átnevezzük a vezérlőt egy általánosabb „HelloController”-re, majd definiáljuk. két külön módszer, Helló() és a viszontlátásra(). Két külön útvonalat is meg kell határoznunk, amelyek a /Helló és a / viszontlátásra URI-k a megfelelő metódusukhoz a vezérlőn. Ez kívánatos egy útvonalfájl felhízlalásához képest, ahol az egyes útvonalak megvalósítása visszahívási függvényként van definiálva.
A Laravel rendelkezik azzal a beépített képességgel, hogy gyorsítótárazza az összes útvonal-definíciót az alkalmazásban, így felgyorsítja az adott útvonal megtalálásához szükséges időt (növeli az alkalmazás teljesítményét); azonban, ezt csak akkor tudja kihasználni, ha az alkalmazáson belül az összes meghatározott útvonal vezérlőspecifikus leképezésekkel van konfigurálva (lásd a fenti 2. példát).

Futtassuk ezt a parancsot, amely egy új vezérlőt generál számunkra.

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

Ez a parancs lényegében az /app/Http/Controllers/UploadController.php címen található fő vezérlőkönyvtárban létrehoz egy „UploadController” nevű vezérlőcsonkot. Nyissa meg a fájlt, és nézze meg. Ez nagyon egyszerű, mert ez csak a vezérlő egy kiosztott változata, a megfelelő névtér elérési úttal és a szükséges osztályokkal, ahonnan kiterjeszti.

A kérelem generálása

Mielőtt továbbmennénk ebben a PHP Laravel oktatóanyagban, és néhány változtatást végrehajtanánk az UploadController által generált csonkon, úgy gondolom, ésszerűbb lesz először létrehozni a kérés osztályt. Ennek az az oka, hogy a kérelmet kezelő controller metódusnak be kell írnia a hint-et a kérelem objektumra az aláírásába, lehetővé téve számára a bejövő űrlapadatok automatikus érvényesítését (a szabályok() metódusban meghatározottak szerint. Erről később…) Egyelőre használjuk ismét a kézműves parancsot a kéréscsonk létrehozásához:

php artisan make:request UploadFileRequest

Ez a parancs létrehoz egy UploadFileRequest nevű fájlt az app/Http/Requests/UploadFileRequest mappában. Nyissa ki a csonkot, és nézze meg… Nagyon egyszerűnek találja, mindössze két módszert tartalmaz, az Authorize()-t és a szabályokat.

Az érvényesítési logika létrehozása

Módosítsuk a kéréscsonkot, hogy megfeleljen az alkalmazásunk igényeinek. Módosítsa a fájlt úgy, hogy így nézzen ki:

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

Nem sok változás történt, de vegyük észre, hogy az authorize() metódus mostantól igazat ad vissza false helyett. Ez a módszer dönti el, hogy engedélyezi-e a kérés bekerülését az alkalmazásba. Ha hamisra van állítva, akkor megakadályozza, hogy a kérés bejusson a rendszerbe (ami általában a vezérlő egy metódusa). Ez egy nagyon hasznos hely lenne a felhasználó engedélyezési ellenőrzésére vagy bármely más logikára, amely eldöntheti, hogy a kérés továbbítható-e a vezérlőhöz. Egyelőre csak igazat adunk vissza, hogy engedélyezzük bárminek és mindennek a kérés használatát.

A másik módszer, a rules() az, ahol az érvényesítéssel kapcsolatban minden varázslat megjelenik. Az ötlet egyszerű: adjon vissza egy szabálykészletet tartalmazó tömböt a következő formában:

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

Számos különböző érvényesítési megkötés létezik, amelyeket a Laravel azonnal támogat. Ezek teljes listájáért tekintse meg az online dokumentációt itt . Feltöltési alkalmazásunkhoz két mezőt kell beadni POST-kéréssel a kezelőfelületen található űrlapról. A fileName paraméternek szerepelnie kell az űrlaptörzsben (azaz kötelező), és ez az a fájlnév, amely alatt a fájlt a tárolóban tároljuk (ez a vezérlőben történik – kicsit később térünk ki rá). Azt is megadjuk, hogy a fájlnévnek karakterláncnak kell lennie egy cső karakter (|) és a „string” szó hozzáadásával. A kényszereket mindig cső határolja, így egyetlen sorban megadható az adott mezőhöz bármilyen további kritérium! Micsoda erő!

A második paraméter, a userFile az a tényleges fájl, amelyet a felhasználó egy weboldalon lévő űrlapról tölt fel. UserFile is szükséges és kell legyen egy fájl. Jegyzet: Ha azt vártuk volna, hogy a feltöltött fájl egy kép legyen, akkor helyette a képmegszorítást használjuk, ami korlátozza a népszerű képtípusok közé tartozó fájltípusokat (jpeg, png, bmp, gif vagy svg). Mivel azt szeretnénk, hogy a felhasználó bármilyen típusú fájlt feltölthessen, csak ragaszkodunk a fájlérvényesítési megkötéshez.

Körülbelül ennyi, ami a kérelem objektumhoz tartozik. Fő feladata, hogy egyszerűen tartsa az elfogadható kritériumokat (megszorításokat), amelyeknek az űrlap törzsparamétereinek meg kell felelniük ahhoz, hogy mélyebbre tudjunk lépni az alkalmazásban. Egy másik dolog, amit meg kell jegyezni, hogy ezt a két mezőt (felhasználófájl és fájlnév) is meg kell adni a HTML kódon belül beviteli mezők formájában (a kérelem objektumban lévő névnek megfelelő mezőnévvel).

Felmerülhet a kérdés: biztosan ez határozza meg annak jellemzőit, hogy egy űrlapkérelemnek mit kell tartalmaznia, de hol történik ezeknek a megszorításoknak a tényleges ellenőrzése? Legközelebb erre térünk ki.

A vezérlő módosítása

Nyissa meg az alkalmazást/Http/Controllers/UploadControllert, és hajtsa végre a következő módosításokat:

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

Tehát ez egy meglehetősen egyszerű megközelítés a feltöltött fájlok lemezre mentésére. Íme a fenti upload() metódus bontása:

Írja be a kérés osztályát a vezérlő metódusába, amely a "hús és krumpli" funkciót végzi, hogy automatikusan ellenőrizni tudjuk a bejövő adatokat
Fogja meg a fájlt a kontroller metóduson belüli (most már érvényesített) kérési objektumból (ebben az esetben up()-nak neveztük el, de elnevezhette volna szabványosabb névvel is, például store()).
Vegye ki a fájlnevet a kérésből
Állítsa be a végleges fájlnevet, amelyet a fájl mentéséhez használ. A getClientOriginalExtension() metódus egyszerűen megragadja a feltöltött fájl eredeti kiterjesztését.
Tárolja a fájlt a helyi fájlrendszerben a storeAs() metódussal, a /storage könyvtárban lévő elnevezett elérési utat 1. argumentumként, a fájlnevet pedig másodikként adja át.
JSON-válasz küldése, amely jelzi, hogy a kérés sikeres volt

A Penge sablon

A rejtvény utolsó nagyobb darabja a blade-sablon, amely az összes HTML-t, CSS-t és javascriptet tartalmazza egyszerű alkalmazásunkhoz. Itt van a kód – később elmagyarázzuk.

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

Itt van a miénk / feltöltés oldal így néz ki:

Ez egy nagyon tipikus példa a pengefájlra, amely egy HTML űrlapot és javascript/jQuery-t tartalmaz az aszinkron funkciók hozzáadásához (hogy az oldal ne frissüljön). Van egy alap címkét method attribútum nélkül (amit csak egy másodperc alatt elmagyarázok), és egy érdekes művelet attribútummal {{route('file.upload')}} értékkel. A pengében ez az úgynevezett a Irányelv. A direktíva csak a függvény fantáziadús neve – olyan blade-sablonokra jellemző függvények, amelyek különböző műveleteket hajtanak végre, amelyek a weboldalak és webalkalmazások készítésekor jellemzőek. Ha jobban meg szeretné érteni, hogy a blade milyen jó szarságra képes, tekintse meg a dokumentumokat itt . A fenti esetben a route direktívát használjuk URL-cím létrehozására űrlapunk benyújtásához.

Ne feledje, hogy útvonalainkat korábban az alkalmazásban a web.php fájlban határoztuk meg, és mindegyikhez megadtunk egy könnyen megjegyezhető nevet. A {{route()}} direktíva elfogad egy útvonalnevet, megkeresi a belső gyorsítótárban tárolt útvonallistában, és létrehoz egy teljes URL-t az útvonal web.php fájlban lévő meghatározása alapján. Ebben az első esetben megadjuk, hogy azt szeretnénk, hogy az űrlap elküldje a beküldött adatait az alkalmazásunk /process URL-jére, amely egy POST útvonalon.

A következő furcsa dolog, amit észrevehetett, a @csrf címke közvetlenül a nyitó űrlapcímke alatt. A blade-ben ez a címke egy _token paramétert hoz létre az űrlapon, amelyet az alkalmazáson belül ellenőriznek az űrlapadatok feldolgozása előtt. Ez biztosítja, hogy az űrlapon belüli adatok érvényes eredetűek legyenek, és megakadályozza a webhelyek közötti kérés-hamisítást. További információért lásd a docs.

Ezek után az űrlapunkat normál módon definiáljuk, azonban ne feledjük, hogy az űrlapparamétereink neve, a userFile és a fileName a pontosan ugyanolyan a kérelem objektumunkban meghatározottak szerint. Ha elfelejtettük megadni a kérésobjektumban meghatározott paraméter bemenetét (vagy hibásan írtuk), a kérés sikertelen lesz, és hibaüzenetet ad vissza, megakadályozva, hogy az eredeti űrlapkérés valaha is elérje az UploadController@ címen található vezérlő metódusát. folyamat .

Próbálja ki, és küldjön be néhány fájlt az alkalmazásba ezen az űrlapon. Ezt követően navigáljon a /lista oldalon megtekintheti a feltöltési mappa tartalmát, a feltöltött fájlokat pedig egy táblázatban:

A Bigger Picture

Tegyünk egy lépést hátra, és nézzük meg, mit tettünk ebben a Laravel-oktatóanyagban.

Ez a diagram az alkalmazást a jelenlegi állapotában ábrázolja (a magas szintű részletek kivételével):

Emlékeztetni kell arra, hogy a Laravel oktatóanyag elején felépített kérelem objektumnak ugyanazokkal a paraméterekkel kell rendelkeznie, mint a blade sablonban lévő űrlapon (ha nem, olvassa el újra az „Érvényesítési logika létrehozása”) című részt. . A felhasználó beírja az űrlapot egy weboldalon, amelyet egy blade template engine-en keresztül jelenít meg (ez a folyamat természetesen auto-pilot alatt történik, így nem kell még gondolkodnunk rajta), és elküldi az űrlapot. A sablon alján található jQuery kódja leállítja az alapértelmezett beküldést (ami automatikusan átirányít egy külön oldalra), létrehoz egy ajax kérelmet, betölti a kérést az űrlap adataival és feltölti a fájlt, majd az egészet elküldi a lapunk első rétegébe. pályázat: a kérés.

A kérés objektumot úgy tölti fel a rendszer, hogy a rule() metóduson belüli paramétereket társítja a beküldött űrlapparaméterekhez, majd érvényesíti az adatokat az egyes megadott szabályok szerint. Ha az összes szabály teljesül, akkor a kérés a web.php útvonalfájlban meghatározott értékeknek megfelelő vezérlő metódusához kerül. Ebben az esetben az UploadController process() metódusa végzi a munkát. Amint elértük a vezérlőt, már tudjuk, hogy a kérés átment az érvényesítésen, így nem kell újra tesztelnünk, hogy a megadott fájlnév valójában egy karakterlánc, vagy a userFile paraméter valóban tartalmaz-e valamilyen fájltípust… Folytathatjuk így Normál.

A kontroller metódus ezután kiveszi az érvényesített paramétereket a kérés objektumból, létrehoz egy teljes fájlnevet úgy, hogy az átadott fileName paramétert összefűzi a userFile eredeti kiterjesztésével, eltárolja a fájlt egy könyvtárban az alkalmazásunkban, majd visszaad egy egyszerű JSON-kódolású fájlt. válasz, amely igazolja, hogy a kérelem sikeres volt. A választ a jQuery logika fogadja, amely néhány további felhasználói felülettel kapcsolatos feladatot végez, például megjeleníti a siker- (vagy hiba-) üzenetet 5 másodpercig, majd elrejti, valamint törli a korábbi űrlapbejegyzéseket… ez azért van, hogy a felhasználó tudja győződjön meg arról, hogy a kérés sikeres volt, és ha akarnak, újabb fájlt tölthetnek fel.

Azt is vegye figyelembe a fenti diagramon, hogy hol húzódik meg a határvonal a kliens és a szerver között. Ez a koncepció rendkívül fontos, hogy megértse, és segít megoldani azokat a problémákat és problémákat, amelyek a jövőben felmerülhetnek, amikor például több aszinkron kéréssel zsonglőrködik, amelyek bármikor előfordulhatnak. Az elválasztás közvetlenül a kérési objektum határán van. Maga a kérelem objektum az alkalmazás többi részéhez vezető „átjárónak” tekinthető… Ez végzi el a webböngészőből átadott űrlapértékek kezdeti érvényesítését és regisztrálását. Ha ezek érvényesnek minősülnek, akkor az a vezérlőhöz folytatódik. Minden azelőtt a kezelőfelületen található (a „kliens” szó szerint azt jelenti, hogy „a felhasználó számítógépén”). A válasz visszakerül az alkalmazásból az ügyféloldalra, ahol a jQuery kódunk türelmesen figyeli, hogy megérkezik-e, és miután megkapta, néhány egyszerű felhasználói felületi feladatot végrehajt.

Közel 90+ fontos, gyakran ismételt kérdéssel foglalkoztunk Laravel és PHP kapcsolatos interjúkérdések pályakezdőknek, valamint tapasztalt jelölteknek a megfelelő állás megszerzéséhez.