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 Laravel-t Taylor Otwell fejlesztette ki. A 2011 júniusi első megjelenése (1. verzió) óta folyamatosan egyre népszerűbb a webfejlesztési iparág PHP-keretrendszer szektorában. Ez a népszerűség nagyrészt a számos fejlesztőközpontú funkciónak tudható be, amelyekkel alapértelmezés szerint rendelkezik.

Miért Laravel?

2000 körül a legtöbb PHP kód 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 viszonylag könnyen karbantartási rémálommá válhatott. A világnak valami jobbra volt szüksége. Íme a PHP 5-ös verziója és a különféle PHP keretrendszerek, amelyek megpróbáltak egy nagyon is szükséges struktúrát és jobb megoldásokat kínálni a webes alkalmazások különféle problémáira.

Azóta számos keretrendszer jelent meg, amelyek utat nyitottak a ma is használatos népszerű keretrendszereknek. Ma a három legjobb (véleményünk szerint) a Zend Framework, a Symfony és természetesen a Laravel lenne. Bár ezek a keretrendszerek hasonló elveken alapultak, és (alapvetően) ugyanazon gyakori problémák megoldására irányulnak, a fő különbségek a megvalósításukban rejlenek. Mindegyiknek megvannak a saját sajátosságai a problémák megoldásában. Ha megnézzük az egyes keretrendszerek által készített kódot, látni fogjuk, hogy egy meglehetősen éles 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 különbség a Laravel és a CodeGyújtó.

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

Jegyzet: Ez az oktatóanyag Laravel 5.8-as verzióhoz készült, de az útvonalválasztás, a vezérlő, a kérés és a Blade koncepciók változatlanok maradnak a jelenlegi kiadásokban. 2026-tól a legújabb verzió a Laravel 13 (2026 márciusában jelent meg), amelyhez PHP 8.3 vagy újabb verzió szükséges, míg a Laravel 12-höz PHP 8.2 szükséges.

Jegyzet: Feltételezzük, hogy már van telepítve egy PHP példány a helyi rendszereden. Ha nem, akkor elolvashatod, hogyan telepítheted. 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:

Jegyzet: A Laravel beállításával kapcsolatos részletesebb utasításokért lásd a Laravel dokumentációját. itt .

Látni fogja, ahogy 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, mi a Laravel composer szkripttel fogjuk ezt megtenni. A szkript telepítéséhez futtassa a következőt:

composer global require laravel/installer

Ami valahogy így fog kinézni:

Ez letölti és telepíti az összes keretrendszer-fájlt, valamint az összes szükséges függőséget. A csomagok a gyártó könyvtárába lesznek mentve. A letöltés és telepítés után a folyamat egyszerűen a következő parancs kiadásával végezhető el:

laravel new uploadApp

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

A Composer telepíti az összes csomagot, amire a Laravelnek szüksége van a futtatáshoz. Ez eltarthat néhány percig, ezért légy türelmes. Miután befejeződött, futtasd az ls -al parancsot, hogy megnézd, 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áskódunk található. Minden vezérlő, szabályzat és modell ebben a mappában található.
• bootstrap/ : Az alkalmazás indító szkriptjét és néhány osztálytérkép-fájlt tárolja.
• config/ : Az alkalmazás konfigurációs fájljait tárolja. Ezeket általában nem módosítják közvetlenül, hanem az alkalmazás gyökerében található .env (környezet) fájlban beállított értékekre támaszkodnak.
• adatbázis/ : Az adatbázisfájlokat tartalmazza, beleértve a migrációkat, a seedeket és a tesztgyárakat.
• nyilvános/ : Nyilvánosan elérhető mappa, amely a lefordított forrásokat és természetesen egy index.php fájlt tartalmazza.
• erőforrások/ : Tartalmaz előtér-elemeket, például JavaSzkriptfájlok, nyelvi fájlok, CSS/SASS fájlok és az alkalmazásban használt összes sablon (más néven blade sablonok).
• útvonalak/ : Az alkalmazás összes útvonala itt található. Az útvonalaknak több különböző „hatóköre” van, de most a web.php fájlra fogunk összpontosítani.
• tárolás/ : Az alkalmazás által használt összes ideiglenes gyorsítótárfájl, munkamenet-fájlok, lefordított nézetfájlok és naplófájlok.
• tesztek/ : Az alkalmazás tesztfájljait tartalmazza, például egységteszteket és funkcionális teszteket.
• eladó/ : Minden függőségi csomag telepítve van a composerrel.

Most pedig építsük fel az alkalmazás többi részét, és futtassuk egy speciális Artisan paranccsal (hogy megspóroljuk magunknak egy webszerver, például az Apache vagy az nginx telepítésének és konfigurálásának nehézségeit). Az .env fájl tartalmazza az összes konfigurációs értéket, amelyet a /config könyvtárban található fájlok az alkalmazás konfigurálásához használnak.

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:

1. webes űrlapról történő fájlfeltöltések kezelése
2. a korábban feltöltött fájlokat egy másik oldalon jelenítse meg.

Ebben a projektben az alkalmazásunk csak írási jogosultsággal fog rendelkezni, 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ének megkezdéséhez. Fontos megjegyezni, hogy a rövidség kedvéért kizártuk az adatbázis-modellezést, a migrációkat és a hitelesítést, de egy valós alkalmazásban ezek további dolgok, 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 meghatározza azt a végpontot, amely a feltöltött fájl mentésének logikájára mutat.
• A ellenőr amely kezeli a kérés-válasz folyamatot.
• A sablon amely a korábban feltöltött fájlok listájának és magának a feltöltési űrlapnak a megjelenítésére szolgál.
• A kérni amelyet a vezérlő a webes űrlapról bevitt adatok érvényesítésére fog használni.

Mi az az útvonal?

A Laravelben egy útvonal alapvetően egy URI által meghatározott végpont, amely „mutatóként” működik az alkalmazás által kínált valamilyen funkcióra. Leggyakrabban egy útvonal egyszerűen egy vezérlőn lévő metódusra mutat, és azt is megszabja, hogy mely HTTP metódusok tudják elérni az adott URI-t. Az útvonal nem mindig jelent vezérlő metódust sem; egyszerűen átadhatja az alkalmazás végrehajtását egy definiált Closure vagy anonymous függvénynek is.

Miért érdemes útvonalat használni?

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 nyilvánosan elérhető „böngészőalapú” útvonalak. Ezek a leggyakoribbak, és ezeket éri a webböngésző. Áthaladnak a webes köztes szoftvercsoporton, és a következőkhöz is tartalmaznak szolgáltatásokat: CSRF-védelem (ami segít védekezni az űrlap-alapú rosszindulatú támadások ellen), és általában bizonyos fokú „állapotot” tartalmaznak (ez alatt azt értjük, 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 middleware-ek. Ezek az útvonalak állapot nélküliek, és nincsenek munkameneteik vagy keresztkéréses memóriájuk (egyetlen kérés nem oszt meg adatokat vagy memóriát más kérésekkel; mindegyik önmagába van csomagolva).
• console.php: ezek az útvonalak az alkalmazásodhoz létrehozott egyéni Artisan parancsoknak felelnek meg.
• channels.php: útvonalakat regisztrál az események közvetítéséhez.

A legfontosabb fájl, amivel most foglalkoznunk kell, a böngészőspecifikus fájl, a web.php. Van egy alapértelmezés szerint definiált útvonal, amelyre jobbra kattintva navigálsz az alkalmazásod webgyökérébe (a webgyökér a nyilvános könyvtárban található). Három különböző útvonalra lesz szükségünk ahhoz, hogy a feltöltési alkalmazásunk működjön:

• /upload: ez lesz a fájlok feltöltésére szolgáló webes űrlapunkat megjelenítő főoldal URI-ja.
• /process: ide küldi az /upload URI-n található űrlap az űrlap által beküldött adatokat (az űrlap „művelete”).
• /list: ez listázza az oldalra feltöltött összes fájlt.

Jegyzet: A /list végpontra esetleg nincs 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 oldalra szeretnénk helyezni; azonban egyelőre külön tartottuk őket, hogy egy kicsit több információt adjunk a szóban forgó témához.

//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 bemutatóban minden kívánt útvonalat explicit módon felsorolunk a web.php routes fájlban a rendelkezésre álló HTTP-specifikus kérési metódusok (get(), post(), put(), delete(), patch() vagy options()) egyikének használatával. Ezek részletesebb leírását itt találja: ezt ki. Ezek a metódusok meghatározzák, hogy mely HTTP-műveletek férhetnek hozzá az adott útvonalhoz. Ha olyan útvonalra van szükséged, amely egynél több HTTP-műveletet is képes elfogadni (ami akkor fordulhat elő, ha egyetlen oldalt használsz a kezdeti adatok megjelenítésére és a beküldött űrlapadatok közzétételére), akkor használhatod a Route::any() metódust.

A Route::get() és a Route::post() metódusok (és a Route homlokzaton található bármely más HTTP-igével kapcsolatos metódus) második argumentuma egy adott vezérlő neve és a vezérlőben található metódus, amely a megengedett HTTP-kéréssel (GET, POST, PATCH stb.) az útvonal végpontjához érve végrehajtódik. Az UploadController metódust használjuk az összes útvonalhoz, és a következő módon adtuk meg őket:

Az utolsó metódus, amit minden útvonalon meghívunk, a name() függvény, ami egyetlen karakterláncot fogad el argumentumként, és arra szolgál, hogy egy adott útvonalat többé-kevésbé „megcímkézzünk” egy könnyen megjegyezhető névvel (a mi esetünkben upload, process és list). Lehet, hogy nem tűnik olyan nagyszerű funkciónak, hogy minden útvonalnak saját nevet adjunk, amikor a URL pontosan ugyanaz a neve, de igazán hasznos, ha van egy adott útvonalad, például a /users/profile/dashboard/config, ami könnyebben megjegyezhető profile-admin vagy user-config néven.

Megjegyzés a homlokzatokról:

• A facade-ok „statikus” interfészt biztosítanak az alkalmazás szolgáltatáskonténerében elérhető osztályokhoz.
• 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ókban a Route facade-et használjuk ahelyett, hogy manuálisan példányosítanánk egy új Illuminate/Routing/Router objektumot, és meghívnánk a megfelelő metódusokat az adott objektumon. Ez csak egy rövidítés, ami időt takarít meg.pingA Laravel keretrendszerben gyakran használják a homlokzatokat; érdemes és érdemes is megismerkedni velük. A homlokzatokról szóló dokumentáció megtalálható. 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: fogadja a kérést az ügyféltől, és választ küld az ügyfélnek. Ez a lényegre törő definíció, és egyben bármely adott vezérlő minimális követelménye is. Amit e két dolog között csinál, azt általában a vezérlő „műveletének” (vagy az „útvonal implementációjának”) tekintik. Ez a második belépési pont az alkalmazásba (az első a kérés) a kliens számára, aki elküldi a kérés hasznos adatát (erre a következőkben térünk ki) az alkalmazásnak, valamilyen választ várva (sikeroldal, átirányítás, hibaoldal vagy bármilyen más HTTP-válasz formájában).

Egy vezérlő (alapvetően) ugyanazt csinálja, mint egy útvonaldefiníció, amely egy anonim függvénnyel „műveletként” van beállítva, amikor az adott útvonalat eléri a rendszer. A különbség az, hogy egy vezérlő jól kezeli az aggályok szétválasztását, míg egy útvonal a tényleges útvonalhoz igazodik. URL definíció, ami alapvetően azt jelenti, hogy az útvonalhoz rendelt URI-t összekapcsoljuk az útvonal implementációjával, vagyis azzal a kóddal, amely akkor fut, amikor az adott útvonalat eléri a rendszer.

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: A route definíciója a routes/web.php fájlban található, de a megvalósítása az /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 2. Laravel példa sokkal több munkának tűnik (ami nem az, csak egy kicsit több kód), nézzük meg, milyen előnyöket nyerünk, ha az adott „hello-world” útvonalhoz tartozó műveleti logikánkat egy vezérlőn belülre helyezzük, ahelyett, hogy az útvonalat visszahívó függvényként definiálnánk:

1. Logikánk tisztán elkülönül a saját osztályában (aggodalmak szétválasztása).
2. A vezérlőnket későbbi bővítésre is beállíthatjuk, ha további funkciókat szeretnénk hozzáadni. Tegyük fel, hogy egy „viszlát világ” funkciót szeretnénk hozzáadni. Ebben az esetben átnevezzük a vezérlőt egy általánosabb „HelloController”-re, majd két külön metódust definiálunk, 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 ahhoz képest, mintha egy útvonalfájlt hizlalnánk fel, ahol minden útvonal implementációja visszahívó függvényként van definiálva.
3. 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, csak akkor tudod kihasználni ezt, ha az alkalmazáson belüli összes meghatározott útvonalad vezérlőspecifikus térképpel van konfigurálva.pings (lásd a fenti 2. példát).

Futtassuk le ezt a parancsot, amely létrehoz nekünk egy új vezérlőt.

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

Lényegében ez a parancs egy „UploadController” nevű vezérlő csonkot generál a vezérlő fő könyvtárában, a /app/Http/Controllers/UploadController.php címen. Nyisd meg ezt a fájlt és nézd meg. Nagyon egyszerű, mert ez csak a vezérlő egy csonkolt verziója, a megfelelő névtér-elérési úttal és a szükséges osztályokkal, amelyekből kiindul.

A kérelem generálása

Mielőtt továbblépnénk ebben a PHP Laravel bemutatóban, és néhány módosítást végeznénk az UploadController generált csonkján, logikusabb először a kérésosztályt létrehozni. Ez azért van, mert a kérést kezelő vezérlőmetódusnak típushivatkozással kell ellátnia a kérésobjektumot az aláírásában, lehetővé téve számára, hogy automatikusan validálja a bejövő űrlapadatokat (ahogyan azt a rules() metódus meghatározza; erről később). Most használjuk ismét az artisan parancsot a kéréscsonk generálásához:

php artisan make:request UploadFileRequest

Ez a parancs létrehoz egy UploadFileRequest nevű fájlt az app/Http/Requests/UploadFileRequest könyvtárban. Nyisd meg a stubot, és nézd meg. Nagyon egyszerűnek fogod találni, mindössze két metódust tartalmaz, az authorize() és a rules() metódusokat.

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

Módosítsuk a kéréscsonkokat az alkalmazásunk igényeinek megfelelően. Módosítsuk 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 igaz értéket ad vissza a hamis helyett. Ez a metódus dönti el, hogy engedélyezi-e a kérés bejutását az alkalmazásba. Ha hamis értékre van állítva, akkor megakadályozza, hogy a kérés bejusson a rendszerbe. Ez egy nagyon hasznos hely lenne a felhasználó jogosultságellenőrzéseinek vagy bármilyen más logika elvégzésére, amely eldöntheti, hogy a kérés továbbítható-e a vezérlőhöz. Egyelőre csak igaz értéket adunk vissza, hogy bármi és minden használhassa a kérést.

A másik metódus, a rules() az, ahol az összes varázslat a validációval kapcsolatban megjelenik. Az ötlet egyszerű: adjon vissza egy tömböt, amely egy szabályhalmazt tartalmaz 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 A feltöltési alkalmazásunkhoz két mezőt kell megadnunk egy POST kérésen keresztül egy űrlapról a kezelőfelületen. A fileName paraméternek az űrlap törzsében kell lennie (azaz kötelező), és ez a fájlnév, amely alatt a fájlt a tárolóban tároljuk (ezt a vezérlőben tehetjük meg; erre kicsit később térünk ki). Azt is megadjuk, hogy a fájlnévnek karakterláncnak kell lennie, egy függőleges vonal (|) és a 'string' szó hozzáadásával. A korlátozásokat mindig függőleges vonal választja el egymástól, így egyetlen sorban megadhatunk további feltételeket az adott mezőhöz.

A második paraméter, a userFile, az a fájl, amelyet a felhasználó feltölt egy weboldalon található űrlapról. A userFile paraméter megadása szintén kötelező. kell legyen egy fájl. Jegyzet: Ha azt vártuk, hogy a feltöltött fájl kép legyen, akkor a képmegszorítást használnánk, ami korlátozná a népszerű képtípusok (jpeg, png, bmp, gif vagy svg) közül elfogadott fájltípusokat. Mivel azt szeretnénk, hogy a felhasználó bármilyen típusú fájlt feltölthessen, a fájlérvényesítési megszorításnál maradunk.

Ez nagyjából minden, ami a request objektumhoz tartozik. Fő feladata egyszerűen az elfogadható kritériumok (megszorítások) halmazának tárolása, amelyeket az űrlap törzsparamétereinek teljesíteniük kell ahhoz, hogy továbbléphessenek az alkalmazásban. Fontos megjegyezni, hogy ezt a két mezőt (userFile és fileName) a HTML kódban is meg kell adni beviteli mezők formájában (a mezőnévnek meg kell egyeznie a request objektumon belüli névvel).

Felmerülhet a kérdés: ez határozza meg, hogy mit kell tartalmaznia egy űrlapkérésnek, de hol történik ezeknek a korlátozásoknak a tényleges ellenőrzése? Erre a következő lépésben 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 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
}
}

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

• Írd be a kérésosztályt a vezérlő metódusába, amely a fő funkciókat végzi, hogy automatikusan validálhassuk a bejövő adatokat.
• Vegye ki a fájlt a (most már validált) kérésobjektumból a vezérlő metóduson belül.
• 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.
• Egy JSON-választ ad vissza, amely jelzi, hogy a kérés sikeres volt.

A Penge sablon

A kirakós utolsó fő darabja a penge sablon, amely az összes HTML, CSS és ... kódot tartalmazza. JavaSzkript az egyszerű alkalmazásunkhoz. Itt a kód; később elmagyarázzuk.

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

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

Ez egy nagyon tipikus példa egy HTML űrlapot tartalmazó blade fájlra, és JavaSzkript/jQuery aszinkron funkciók hozzáadásához (így az oldal nem frissül). Van egy alapvető egy method attribútum nélküli tag (amit mindjárt elmagyarázunk), és egy érdekes action attribútummal, amelynek értéke {{route('process')}}. Blade-ben ez az úgynevezett Irányelv. Az irányelv csupán egy függvény fantáziadús elnevezése; ezek olyan függvények, amelyek a blade sablonokra jellemzőek, és a weboldalak és webes alkalmazások létrehozásánál gyakran előforduló műveleteket hajtanak végre. A blade összes hasznos funkciójának jobb megértéséhez tekintse meg a dokumentációt. itt A fenti esetben a route direktívát használjuk egy URL az űrlap beküldéséhez.

Ne feledd, hogy az útvonalakat korábban, az alkalmazásban definiáltuk a web.php fájlban, mindegyikhez egy könnyen megjegyezhető nevet adva. A {{route()}} direktíva elfogadja az útvonal nevét, kikeresi azt a belsőleg gyorsítótárazott útvonallistában, és létrehoz egy teljes URL a web.php fájlban található útvonal definíciója alapján. Ebben az első esetben azt adjuk meg, hogy az űrlap a beküldött adatokat a /process-nek küldje el. URL alkalmazásunk, amelyet úgy definiálunk, mint egy POST útvonalon.

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

Ezután az űrlapunkat normálként definiáljuk; azonban vegyük figyelembe, hogy az űrlapparamétereink nevei, a userFile és a fileName, a következők: pontosan ugyanolyan ahogyan azt a kérésobjektumunkban definiáljuk. Ha elfelejtenénk megadni egy bemenetet egy adott paraméterhez, amely a kérésobjektumban van definiálva (vagy elgépelnénk), a kérés sikertelen lenne, és hibaüzenetet adna vissza, megakadályozva, hogy az eredeti űrlapkérés valaha is elérje az UploadController@process címen található vezérlőmetódust.

Próbáld ki, és küldj be néhány fájlt az alkalmazásnak ezen az űrlapon keresztül. Ezután navigálj a következőhöz: /lista oldalon megtekintheti a feltöltési mappa tartalmát, a feltöltött fájlokat pedig egy táblázatban:

A Bigger Picture

Lépjünk egyet hátra, és nézzük meg, mit is csináltunk ebben a Laravel oktatóanyagban.

Ez a diagram a kérelmet jelenlegi állapotában ábrázolja (a részletesebb információk nélkül):

Ne feledd, hogy a Laravel oktatóanyag elején létrehozott kérésobjektum rules metódusában ugyanazokkal a paraméterekkel kell rendelkeznie, mint amelyek a blade sablon űrlapján vannak definiálva (ha nem, olvasd el újra az „Érvényesítési logika létrehozása” részt). A felhasználó egy weboldalon adja meg az űrlapot, amelyet a blade sablonmotor renderel, és elküldi az űrlapot. A sablon jQuery kódja alul leállítja az alapértelmezett elküldést (ami automatikusan egy külön oldalra irányítana át), létrehoz egy ajax kérést, betölti a kérést az űrlapadatokkal és a feltöltött fájllal, és az egészet elküldi az alkalmazásunk első rétegébe: a kérésbe.

A kérés objektum úgy töltődik fel, hogy a rules() metódus paramétereit társítja a beküldött űrlapparaméterekkel, majd az adatokat minden megadott szabály szerint validálja. Ha minden szabály teljesül, a kérés továbbkerül ahhoz a vezérlő metódushoz, amely megfelel a web.php útvonalfájlban definiált értékeknek. Ebben az esetben az UploadController process() metódusa végzi a munkát. Amint elérjük a vezérlőt, már tudjuk, hogy a kérés átment az validáción, így nem kell újra tesztelnünk, hogy a megadott fájlnév valóban karakterlánc-e, vagy a userFile paraméter valóban valamilyen típusú fájlt tartalmaz. Folytathatjuk a szokásos módon.

A vezérlő metódus ezután kiolvassa a validált paramétereket a kérés objektumból, létrehoz egy teljes fájlnevet az átadott fileName paraméter és a userFile eredeti kiterjesztésének összefűzésével, elmenti a fájlt egy könyvtárban az alkalmazásunkban, majd egy egyszerű JSON-kódolású választ ad vissza, amely ellenőrzi, hogy a kérés sikeres volt-e. A választ a jQuery logika fogadja, amely további, a felhasználói felülettel kapcsolatos feladatokat hajt végre, például 5 másodpercig megjeleníti a siker (vagy hiba) üzenetet, majd elrejti azt, és kitörli az előző űrlapbejegyzéseket. Ez azért van, hogy a felhasználó biztosan tudja, hogy a kérés sikeres volt, és feltölthet egy másik fájlt, ha akar.

Figyeld meg a fenti ábrán azt is, hogy hol húzódik a határvonal a kliens és a szerver között. Ez a koncepció abszolút elengedhetetlen ahhoz, hogy megértsd, és segít megoldani a jövőben felmerülő problémákat és nehézségeket, például amikor több aszinkron kérést kezelsz, amelyek bármikor előfordulhatnak. Az elválasztás pontosan a kérésobjektum határán van. Maga a kérésobjektum tekinthető az alkalmazás többi részéhez vezető „átjárónak”. Ez végzi a webböngészőből átadott űrlapértékek kezdeti ellenőrzését és regisztrációját. Ha érvényesnek nyilvánítja őket, akkor továbblép a vezérlőhöz. Minden, ami előtte van, a front-end-en található (a „kliens” szó szerint azt jelenti, hogy „a felhasználó számítógépén”). A választ az alkalmazás visszaküldi a kliens oldalra, ahol a jQuery kódunk türelmesen figyeli az érkezését, és néhány egyszerű felhasználói felületi feladatot hajt végre, miután megkapta.

Számos fontos, gyakran ismételt kérdést is érintettünk Laravel és PHP kapcsolatos interjúkérdések pályakezdőknek, valamint tapasztalt jelölteknek a megfelelő állás megszerzéséhez.

GYIK