Урок за Laravel за начинаещи

Какво е Laravel?

Laravel е уеб MVC рамка с отворен код за PHP. Laravel е стабилна рамка, която осигурява лесна разработка на PHP уеб приложения с функции като модулна система за пакетиране със специален мениджър на зависимости, достъп до релационни бази данни и други помощни програми за внедряване и поддръжка на приложения.

Laravel е създаден от Тейлър Отуел. От първоначалното си пускане през юни 2011 г. (версия 1), той непрекъснато набира популярност в сектора на PHP фреймворка в индустрията за уеб разработка. Голяма част от тази популярност може да се отдаде на многото функции, насочени към разработчиците, с които се предлага по подразбиране.

Защо Laravel?

Около 2000 г., повечето PHP код беше процедурен и можеше да бъде намерен под формата на „скриптове“, които биха имали заплетена бъркотия от спагети код. Дори най-простите страници нямаха разделяне на загрижеността, и по този начин беше сравнително лесно едно приложение бързо да се превърне в кошмар за поддръжка. Светът се нуждаеше от нещо по-добро. Появява се PHP версия 5 и различни PHP рамки, опитващи се да внесат така необходимата структура и по-добри решения за различни проблеми с уеб приложенията.

Оттогава сме свидетели на пускането на много рамки, които проправят пътя за популярните рамки, използвани днес. Днес, според нас, първите три биха били Zend Framework, Symfony и, разбира се, Laravel. Въпреки че всяка от тези рамки е основана на сходни принципи и е насочена към решаване (по принцип) на едни и същи често срещани проблеми, ключовите им разлики се крият в техните имплементации. Всяка от тях има свои собствени особености относно начина на решаване на проблеми. Когато погледнете кода, създаден от всяка от тях, ще видите, че има доста плътна граница, която ги разделя една от друга. Според нашето скромно мнение, рамката Laravel е най-добрата.

Научете повече за разликата между Laravel и Codeподпалвач.

Как да изтеглите и инсталирате Laravel с Composer

Забележка: Този урок е написан за Laravel 5.8, но концепциите за маршрутизация, контролер, заявка и Blade остават същите в текущите версии. Към 2026 г. най-новата версия е Laravel 13 (издадена през март 2026 г.), която изисква PHP 8.3 или по-нова версия, докато Laravel 12 изисква PHP 8.2.

Забележка: Предполага се, че вече имате инсталирано копие на PHP на вашата локална система. Ако не, можете да прочетете как да го инсталирате тук.

Composer е както пакет, така и мениджър на зависимости. За да го инсталирате, отворете терминал и CD в нова директория. Изпълнете тази команда:

curl -Ss getcomposer.org/installer | php

Резултатите от тази команда ще изглеждат така:

Забележка: За по-подробни инструкции относно настройката на Laravel, вижте документацията на Laravel тук.

Ще видите как се изтегля и компилира скриптът composer.phar, който използваме за инсталиране на Laravel. Въпреки че има много начини за създаване на ново Laravel приложение, ние ще го направим чрез скрипта composer на Laravel. За да инсталирате този скрипт, изпълнете:

composer global require laravel/installer

Което ще изглежда така:

Това ще изтегли и инсталира всички файлове на рамката, както и всички зависимости, които са необходими. Пакетите ще бъдат запазени в директорията на доставчика. След като изтеглите и инсталирате, е лесно да издадете следната команда:

laravel new uploadApp

Ще видите нещо като следния изход:

Composer инсталира всички пакети, от които Laravel се нуждае, за да работи. Може да отнеме няколко минути, така че бъдете търпеливи. След като приключи, изпълнете командата ls -al, за да видите какво е инсталирано.

Ето кратка разбивка на директориите в обикновено приложение на Laravel:

• приложение/ : Това е папката с изходния код, където се намира кодът на нашето приложение. Всички контролери, политики и модели са в тази папка.
• зареждане/: Съдържа стартовия скрипт на приложението и няколко файла с карта на класове.
• конфигурация/: Съдържа конфигурационните файлове на приложението. Те обикновено не се променят директно, а вместо това разчитат на стойностите, зададени във файла .env (environment) в основата на приложението.
• база данни/ : Съхранява файловете на базата данни, включително миграции, начални параметри и фабрики за тестове.
• публичен/ : Публично достъпна папка, съдържаща компилирани ресурси и, разбира се, файл index.php.
• ресурси/ : Съдържа front-end ресурси, като например JavaСкрипт файлове, езикови файлове, CSS/SASS файлове и всички шаблони, използвани в приложението (наричани шаблони за blade).
• маршрути/ : Всички маршрути в приложението са тук. Има няколко различни „обхвата“ на маршрутите, но този, върху който ще се съсредоточим, е файлът web.php.
• съхранение/ : Всички временни кеш файлове, използвани от приложението, файлове на сесията, компилирани скриптове за изглед и лог файлове.
• тестове/ : Съдържа тестови файлове за приложението, като например модулни тестове и функционални тестове.
• продавач/ : Всички пакети със зависимости са инсталирани с composer.

Сега нека изградим останалата част от приложението и да го стартираме със специална команда на artisan (за да си спестим неудобството от инсталирането и конфигурирането на уеб сървър като Apache или nginx). Файлът .env съдържа всички конфигурационни стойности, които файловете в директорията /config използват за конфигуриране на приложението.

Дизайн на приложението: Кратък преглед на нашите изисквания

В този онлайн урок за Laravel ще изградим много просто приложение, което ще прави само две неща:

1. обработва качвания на файлове от уеб формуляр
2. покажете предварително качените файлове на друга страница.

За този проект, нашето приложение ще бъде само за запис, което означава, че потребителят може само да записва файлове и да преглежда списъка с файловете, които е качил. Това приложение е изключително основно, но би трябвало да ви послужи като добра практика, за да започнете да развивате уменията и знанията си за Laravel. Обърнете внимание, че за краткост сме изключили моделирането на бази данни, миграциите и удостоверяването, но в реално приложение това са допълнителни неща, които ще искате да вземете предвид.

Ето списък с компоненти, които ще ни трябват, за да накараме приложението да работи според очакванията:

• A маршрут което ще позволи на външния свят (интернет) да използва приложението, както и ще посочи крайната точка, която ще сочи къде се намира логиката за запазване на качения файл.
• A регулатор който обработва потока от заявка до отговор.
• A шаблон който ще се използва за показване на списък с предварително качени файлове и самия формуляр за качване.
• A поиска които контролерът ще използва за валидиране на данните, предадени от уеб формуляра.

Какво е маршрут?

Маршрутът в Laravel е по същество крайна точка, определена от URI, който действа като „указател“ към някаква функционалност, предлагана от приложението. Най-често маршрутът просто сочи към метод на контролер и също така диктува кои HTTP методи могат да достигнат до този URI. Маршрутът не винаги означава и метод на контролер; той може просто да предаде изпълнението на приложението на дефинирана функция за затваряне или анонимна функция.

Защо да използваме маршрут?

Маршрутите се съхраняват във файлове в папката /routes в основната директория на проекта. По подразбиране има няколко различни файла, съответстващи на различните „страни“ на приложението („страни“ идва от методологията на шестоъгълната архитектура). Те включват:

• web.php: публично достъпните маршрути, базирани на „браузър“. Те са най-често срещаните и се обработват от уеб браузъра. Те преминават през групата за уеб мидълуер и съдържат и функции за CSRF защита (което помага за защитата срещу злонамерени атаки, базирани на формуляри) и обикновено съдържат известна степен на „състояние“ (под това имаме предвид, че използват сесии).
• api.php: маршрути, които съответстват на API група и следователно имат API middleware активиран по подразбиране. Тези маршрути са без състояние и нямат сесии или памет за кръстосани заявки (една заявка не споделя данни или памет с никоя друга заявка; всяка една е самокапсулирана).
• console.php: тези маршрути съответстват на персонализирани команди на artisan, които сте създали за приложението си.
• channels.php: регистрира маршрути за излъчване на събития.

Ключовият файл, с който трябва да се занимаваме в този момент, е специфичният за браузъра файл, web.php. Вече има един маршрут, дефиниран по подразбиране, който е този, който попадате точно когато навигирате към уеб корена на вашето приложение (web root е в public директорията). Ще ни трябват три различни маршрута, за да функционира нашето приложение за качване:

• /upload: това ще бъде URI адресът на главната страница, показваща нашия уеб формуляр за качване на файлове.
• /process: това ще бъде мястото, където формулярът, разположен на /upload URI, публикува данните, изпратени от формуляра („действието“) на формуляра.
• /list: това ще изброи всички файлове, качени на сайта.

Забележка: Крайната точка /list може да не е необходима, ако искаме да поставим цялата логика за показване на формуляра за качване и списъка с файлове на една страница; засега обаче ги запазихме отделно, за да добавим малко повече информация към разглежданата тема.

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

В този урок за Laravel framework, за всеки желан маршрут, ще го изброим изрично във файла с маршрути web.php, използвайки един от наличните HTTP-специфични методи за заявки (get(), post(), put(), delete(), patch() или options()). За разбивка на всеки от тях, вижте това навън. Това, което правят тези методи, е да укажат кои HTTP глаголи имат достъп до дадения маршрут. Ако е необходимо маршрутът да може да приема повече от един HTTP глагол (което може да е така, ако използвате една страница за показване както на началните данни, така и на данните от изпратения формуляр), можете да използвате метода Route::any().

Вторият аргумент на методите Route::get() и Route::post() (и на всеки друг метод, свързан с HTTP-verb, във фасадата на Route) е името на специфичен контролер и методът, разположен вътре в този контролер, който се изпълнява при достигане на крайната точка на маршрута с разрешената HTTP заявка (GET, POST, PATCH и т.н.). Използваме UploadController за всички маршрути и сме ги задали по следния начин:

Последният метод, който извикваме за всеки маршрут, е неговата функция name(), която приема един низ като аргумент и се използва за горе-долу „маркиране“ на определен маршрут с лесно запомнящо се име (в нашите случаи, upload, process и list). Може да не изглежда като толкова добра функция да се дава на всеки маршрут собствено име, когато... URL се казва по абсолютно същия начин, но е наистина полезен, когато имате специфичен маршрут като /users/profile/dashboard/config, който би бил по-лесен за запомняне като profile-admin или user-config.

Бележка за фасадите:

• Фасадите предоставят „статичен“ интерфейс към класове, които са налични в контейнера за услуги на приложението.
• Те предоставят кратък, запомнящ се синтаксис, който ви позволява да използвате функциите на Laravel, без да помните дълги имена на класове, които трябва да бъдат инжектирани или конфигурирани ръчно.

В горните дефиниции на маршрути използваме фасадата Route, вместо ръчно да създаваме инстанции на нов обект Illuminate/Routing/Router и да извикваме съответните методи на този обект. Това е просто пряк път, който спестява време.pingФасадите се използват широко в целия Laravel framework; можете и трябва да се запознаете по-добре с тях. Документацията за Фасади може да бъде намерена тук.

Какво е контролер?

Контролерът е „C“ в архитектурата „MVC“ (Model-View-Controller), на която е базиран Laravel. Работата на контролера може да се сведе до това просто определение: получава заявката от клиента и връща отговор на клиента. Това е основната дефиниция и е и минималното изискване за всеки даден контролер. Това, което прави между тези две неща, обикновено се счита за „действие“ на контролера (или „имплементация на маршрута“). Той действа като втора точка на влизане в приложението (първата е заявката) за клиента, който изпраща полезния товар на заявката (към който ще стигнем по-нататък) към приложението, очаквайки някакъв вид отговор (под формата на страница за успех, пренасочване, страница за грешка или друг вид HTTP отговор).

Контролерът прави (по същество) същото като дефиницията на маршрут с анонимна функция, зададена като „действие“, когато този маршрут бъде достигнат. Разликата е, че контролерът се придържа добре към разделянето на отговорностите, докато маршрутът е дефиниран в съответствие с действителния маршрут. URL дефиниция, което основно означава, че свързваме присвоения URI на маршрута с имплементацията на маршрута или кода, който се изпълнява, когато този маршрут бъде достигнат.

Например, следните две части от код ще постигнат едно и също нещо:

Пример #1: Дефиниция и внедряване на маршрут в едно извикване на метод (във файла с маршрути web.php)

//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: Дефиницията на Route е вътре в routes/web.php, но имплементацията му се намира в класа /app/Http/Controllers/HelloWorldController

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

Въпреки че пример №2 с Laravel изглежда като много повече работа (което не е, просто малко повече код), вижте ползите, които получаваме, като поставим логиката на действието за дадения маршрут „hello-world“ вътре в контролер, вместо с дефиницията на маршрута като функция за обратно извикване:

1. Нашата логика е ясно разделена в собствен клас (разделяне на грижите).
2. Нашият контролер е настроен за по-късно разширение, ако се наложи да добавим допълнителни възможности към него. Да речем, че искаме да добавим функция „сбогом, свят“. В този случай бихме преименували контролера на по-общ „HelloController“, след което бихме дефинирали два отделни метода, здравей() намлява довиждане(). Ще трябва също да дефинираме два отделни маршрута, които картографират /здравей намлява / Довиждане URI адресите към съответния им метод на контролера. Това е желателно в сравнение с увеличаването на файла с маршрути, като имплементацията на всеки маршрут е дефинирана като функции за обратно извикване.
3. Laravel има вградената възможност да кешира всички дефиниции на маршрути в приложението, така че да ускори времето, необходимо за намиране на даден маршрут (увеличава производителността на приложението); Въпреки това, Ще можете да се възползвате от това само ако всички дефинирани маршрути в приложението са конфигурирани с помощта на специфична за контролера карта.pings (вижте Пример №2 по-горе).

Нека изпълним тази команда, която ще генерира нов контролер за нас.

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

По същество, това, което прави тази команда, е да генерира stub за контролер с име „UploadController“ в главната директория на контролера на адрес /app/Http/Controllers/UploadController.php. Чувствайте се свободни да отворите този файл и да го разгледате. Много е просто, защото това е само завършена версия на контролера, с правилния път до пространството от имена и необходимите класове, от които се разширява.

Генериране на заявката

Преди да продължим с това ръководство за PHP Laravel и да направим няколко промени в генерирания stub на UploadController, ще е по-разумно първо да създадем класа request. Това е така, защото методът на контролера, който обработва заявката, трябва да подсказва типа на обекта на заявката в неговата сигнатура, което му позволява автоматично да валидира входящите данни от формуляра (както е посочено в метода rules(); повече за това по-късно). Засега нека използваме командата artisan отново, за да генерираме нашия stub на заявката:

php artisan make:request UploadFileRequest

Тази команда ще генерира файл с име UploadFileRequest в app/Http/Requests/UploadFileRequest. Отворете файла (stub) и го разгледайте. Ще го намерите много прост, съдържащ само два метода, authorize() и rules().

Създаване на логиката за валидиране

Нека модифицираме заявката (request stub), за да отговори на нуждите на нашето приложение. Променете файла така, че да изглежда така:

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

Не са много промени, но обърнете внимание, че методът authorize() вече връща true вместо false. Този метод решава дали да разреши заявката да влезе в приложението. Ако е зададен на false, той спира заявката да влезе в системата. Това би било много удобно място за поставяне на проверки за оторизация на потребителя или друга логика, която може да реши дали заявката може да се придвижи напред към контролера. Засега просто връщаме true тук, за да позволим на всичко и всякакъв вид да използва заявката.

Другият метод, rules(), е мястото, където цялата магия се проявява по отношение на валидирането. Идеята е проста: върнете масив, съдържащ набор от правила във вида:

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

Има много различни ограничения за валидиране, които се поддържат от Laravel направо от кутията. За пълен списък с тях вижте онлайн документацията тукЗа нашето приложение за качване ще има две полета, които се подават чрез POST заявка от формуляр във фронтенд версията. Параметърът fileName трябва да бъде включен в тялото на формуляра (т.е. задължителен) и се използва като име на файл, под което ще съхраняваме файла в хранилището (това се прави в контролера; ще стигнем до него малко по-късно). Също така уточняваме, че името на файла трябва да е низ, като добавяме символа за вертикална черта (|) и думата „низ“. Ограниченията винаги са разделени с вертикални черта, което ви позволява да зададете всякакви допълнителни критерии за даденото поле на един ред.

Вторият параметър, userFile, е действителният файл, който потребителят качва от формуляр на уеб страница. userFile също е задължителен и трябва да да бъде файл. Забележка: Ако очаквахме каченият файл да е изображение, тогава щяхме да използваме ограничението за изображение, което би ограничило типовете файлове, приемани за един от популярните типове изображения (jpeg, png, bmp, gif или svg). Тъй като искаме да позволим на потребителя да качва всякакъв тип файл, ще се придържаме само към ограничението за валидиране на файлове.

Това е горе-долу всичко, което представлява обектът request. Основната му задача е просто да съдържа приемливия набор от критерии (ограничения), на които параметрите на тялото на формуляра трябва да отговарят, за да се продължи по-дълбоко в приложението. Друго нещо, което трябва да се отбележи, е, че тези две полета (userFile и fileName) също трябва да бъдат посочени в HTML кода под формата на полета за въвеждане (като името на полето съответства на името в обекта request).

Може би се питате: това определя характеристиките на това, което трябва да съдържа заявката за формуляр, но къде се извършва действителната проверка на тези ограничения? Ще разгледаме това по-нататък.

Модифициране на контролера

Отворете приложението/Http/Controllers/UploadController и направете следните промени в него:

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

Така че това е сравнително лесен подход за запазване на качените файлове на диск. Ето разбивка на метода process() по-горе:

• Подсказка за типа на класа на заявката в метода на контролера, който изпълнява основната функционалност, за да можем автоматично да валидираме входящите данни.
• Вземете файла от (вече валидирания) обект на заявката вътре в метода на контролера.
• Вземете името на файла от заявката.
• Генерирайте окончателното име на файл, който ще се използва за запазване на файла под. Методът getClientOriginalExtension() просто хваща оригиналното разширение на качения файл.
• Съхранявайте файла в локалната файлова система, като използвате неговия метод storeAs(), като подавате посочения път вътре в директорията /storage като 1-ви аргумент и името на файла, под който да го запишете, като втори.
• Върнете JSON отговор, показващ, че заявката е била успешна.

Шаблонът на острието

Последното основно парче от този пъзел е шаблонът за blade, който ще съдържа всички HTML, CSS и JavaСкрипт за нашето просто приложение. Ето кода; ще го обясним по-късно.

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

Ето какво /качване страницата изглежда така:

Това е много типичен пример за blade файл, съдържащ HTML формуляр и JavaСкрипт/jQuery за добавяне на асинхронна функционалност (така че страницата да не се обновява). Има основен етикет без атрибут method (който ще обясним след малко) и с любопитен атрибут action със стойност {{route('process')}}. В blade това е известно като Директива. Директивата е просто изискано име за функция; това са функции, специфични за шаблони на blade, които изпълняват различни операции, общи за изграждането на уеб страници и уеб приложения. За по-добро разбиране на всички полезни неща, които blade може да прави, разгледайте документацията. тукВ горния случай използваме директивата route, за да генерираме URL за подаването на нашия формуляр.

Не забравяйте, че дефинирахме маршрутите си по-рано в приложението във файла web.php, като зададохме лесно за запомняне име за всеки от тях. Директивата {{route()}} приема името на маршрут, търси го във вътрешно кеширания списък с маршрути и генерира пълен URL въз основа на дефиницията на този маршрут във файла web.php. В този първи случай ние указваме, че искаме формулярът да изпраща подадените данни към /process URL на нашето приложение, което е дефинирано като ПУСНИ маршрут.

Следващото нещо, което може би сте забелязали, е тагът @csrf точно под началния таг на формуляра. В Blade този таг генерира параметър _token във формуляра, който се проверява в приложението, преди да се позволи обработката на данните от формуляра. Това гарантира, че данните във формуляра са с валиден произход и предотвратява атаки за фалшифициране на заявки от друг сайт. За повече информация по този въпрос вижте Документи.

След това дефинираме нашата форма като нормална; имайте предвид обаче, че имената на параметрите на нашата форма, userFile и fileName, са точно същото както е дефинирано в нашия обект на заявка. Ако забравим да включим вход за даден параметър, който е дефиниран в обекта на заявката (или го изпишем неправилно), заявката ще се провали и ще се върне грешка, което ще предотврати достигането на оригиналната заявка за формуляр до метода на контролера, разположен на UploadController@process.

Продължете и го изпробвайте, като изпратите няколко файла към приложението, използвайки този формуляр. След това отидете до /списък страница, за да видите съдържанието на папката за качване, с качените от вас файлове, изброени в таблица:

По-голямата картина

Нека направим крачка назад и да разгледаме какво направихме в този урок за Laravel.

Тази диаграма изобразява приложението в сегашното му състояние (без детайли на високо ниво):

Трябва да си спомните, че обектът request, който създадохме в началото на този урок за Laravel, трябва да има същите параметри, дефинирани в метода му rules, както са във формата в шаблона на blade (ако не, прочетете отново раздела „Създаване на логиката за валидиране“). Потребителят въвежда формуляра на уеб страница, която се рендира чрез двигателя за шаблони на blade, и изпраща формуляра. jQuery кодът на шаблона в долната част спира изпращането по подразбиране (което автоматично би пренасочило към отделна страница), създава ajax заявка, зарежда заявката с данните от формуляра и качения файл и изпраща всичко в първия слой на нашето приложение: заявката.

Обектът на заявката се попълва чрез асоцииране на параметрите в метода rules() с подадените параметри на формуляра, след което валидира данните съгласно всяко зададено правило. Ако всички правила са изпълнени, заявката се предава на метода на контролера, който съответства на стойностите, дефинирани във файла на маршрута web.php. В този случай, методът process() на UploadController върши работата. След като достигнем контролера, вече знаем, че заявката е преминала валидацията, така че не е нужно да проверяваме отново дали даденото име на файл е действително низ или параметърът userFile действително съдържа някакъв тип файл. Можем да продължим както обикновено.

След това методът на контролера извлича валидираните параметри от обекта на заявката, генерира пълно име на файл, като свързва предадения параметър fileName с оригиналното разширение на userFile, съхранява файла в директория в нашето приложение и след това връща прост JSON-кодиран отговор, потвърждаващ, че заявката е била успешна. Отговорът се получава от jQuery логиката, която изпълнява още няколко задачи, свързани с потребителския интерфейс, като например показване на съобщението за успех (или грешка) за 5 секунди, след което скриването му, както и изчистване на предишните записи във формуляра. Това е така, за да знае потребителят със сигурност, че заявката е била успешна и да може да качи друг файл, ако желае.

Също така, обърнете внимание на диаграмата по-горе къде е начертана границата между клиента и сървъра. Тази концепция е абсолютно критична за разбиране и ще ви помогне да решите проблеми, които може да имате в бъдеще, когато жонглирате например с множество асинхронни заявки, които могат да възникнат по всяко време. Разделянето е точно на границата на обекта на заявката. Самият обект на заявката може да се разглежда като „портал“ към останалата част от приложението. Той извършва първоначалната проверка и регистрация на стойностите на формуляра, предадени от уеб браузъра. Ако те се считат за валидни, тогава той продължава към контролера. Всичко преди това е на предния край („клиент“ буквално означава „на компютъра на потребителя“). Отговорът се връща от приложението обратно в клиентската страна, където нашият jQuery код търпеливо слуша за пристигането му и изпълнява няколко прости задачи за потребителския интерфейс, след като го получи.

Разгледахме и много важни често задавани въпроси Въпроси за интервю, свързани с Laravel и PHP както за нови, така и за опитни кандидати, за да получат правилната работа.

Въпроси и Отговори