Підручник 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 є водночас і пакунком, і менеджером залежностей. Щоб установити його, відкрийте термінал і перейдіть у новий каталог. Виконайте цю команду:

curl -Ss getcomposer.org/installer | php

Результати цієї команди виглядатимуть так:

Примітка: Для отримання докладніших інструкцій щодо налаштування Laravel зверніться до документації Laravel. тут.

Ви побачите, як він завантажує та компілює скрипт composer.phar, який ми використовуємо для встановлення Laravel. Хоча існує багато способів налаштування нового застосунку Laravel, ми зробимо це за допомогою скрипта composer Laravel. Щоб встановити цей скрипт, виконайте:

composer global require laravel/installer

Що виглядатиме приблизно так:

Це завантажить та встановить усі файли фреймворку, а також усі необхідні залежності. Пакети будуть збережені в каталозі vendor. Після завантаження та встановлення все просто: виконайте таку команду:

laravel new uploadApp

Ви побачите щось на зразок такого результату:

Composer встановлює всі пакети, необхідні для роботи Laravel. Це може зайняти кілька хвилин, тож будьте терплячі. Після завершення виконайте команду ls -al, щоб переглянути, що було встановлено.

Ось короткий розподіл каталогів у звичайній програмі Laravel:

• додаток/ : Це папка з вихідним кодом, де знаходиться код нашої програми. Усі контролери, політики та моделі знаходяться в цій папці.
• bootstrap/ : Містить сценарій запуску програми та кілька файлів карти класів.
• конфігурація/: Містить файли конфігурації програми. Зазвичай вони не змінюються безпосередньо, а натомість покладаються на значення, встановлені у файлі .env (environment) у кореневому каталозі програми.
• база даних/ : Містить файли бази даних, включаючи міграції, початкові значення та фабрики тестів.
• публічний/ : Загальнодоступна папка, що містить скомпільовані ресурси та, звичайно ж, файл index.php.
• ресурси/ : Містить такі фронтенд-ресурси, як JavaФайли скриптів, мовні файли, файли CSS/SASS та всі шаблони, що використовуються в застосунку (так звані шаблони блейд-програм).
• маршрути/ : Усі маршрути в застосунку знаходяться тут. Існує кілька різних «областей» маршрутів, але ми зосередимося на файлі 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 увімкнене за замовчуванням. Ці маршрути не мають стану та не мають сесій або пам'яті перехресних запитів (один запит не використовує спільні дані чи пам'ять з будь-яким іншим запитом; кожен з них самоінкапсульований).
• console.php: ці маршрути відповідають власним командам artisan, які ви створили для своєї програми.
• channels.php: реєструє маршрути для трансляції подій.

Ключовим файлом, про який потрібно зараз подумати, є файл web.php, специфічний для браузера. За замовчуванням вже визначено один маршрут, той, який ви вибираєте під час переходу до кореневого веб-каталогу вашої програми (кореневий веб-каталог знаходиться у публічному каталозі). Для функціонування нашої програми завантаження нам знадобляться три різні маршрути:

• /upload: це буде URI головної сторінки, на якій відображається наша веб-форма для завантаження файлів.
• /process: це буде місце, куди форма, розташована за URI /upload, надсилатиме дані, надіслані з форми («дія» форми).
• /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, для кожного бажаного маршруту ми явно перерахуємо його у файлі маршрутів web.php, використовуючи один з доступних методів запиту, специфічних для HTTP (get(), post(), put(), delete(), patch() або options()). Розбивку кожного з них див. це вихід. Ці методи вказують, яким HTTP-дієсловам дозволено доступ до цього заданого маршруту. Якщо вам потрібен маршрут, який може приймати більше одного HTTP-дієслова (що може бути у випадку, якщо ви використовуєте одну сторінку для відображення початкових даних та даних форми після надсилання), ви можете скористатися методом Route::any().

Другим аргументом методів Route::get() та Route::post() (і будь-якого іншого методу, пов'язаного з HTTP-дієсловами, на фасаді 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; ви можете і повинні ознайомитися з ними ближче. Документацію щодо Фасадів можна знайти тут.

Що таке контролер?

Контролер — це «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: Визначення маршруту знаходиться всередині 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);
}
}

Хоча приклад Laravel №2 здається набагато складнішим (хоча це не так, просто трохи більше коду), подивіться на переваги, які ми отримуємо, розміщуючи нашу логіку дій для заданого маршруту «hello-world» всередину контролера, а не використовуючи визначення маршруту як функцію зворотного виклику:

1. Наша логіка чітко розділена на власний клас (розділення інтересів).
2. Наш контролер налаштовано на розширення пізніше, якщо нам знадобиться додати до нього додаткові можливості. Скажімо, ми хочемо додати функцію «прощавай, світе». У цьому випадку ми перейменуємо контролер на більш загальний «HelloController», а потім визначимо два окремі методи, привіт() та до побачення(). Нам також потрібно буде визначити два окремих маршрути, які відображатимуть /привіт та / до побачення URI до відповідного методу на контролері. Це бажано порівняно зі збільшенням файлу маршрутів, де реалізація кожного маршруту визначена як функції зворотного виклику.
3. Laravel має вбудовану можливість кешувати всі визначення маршрутів у програмі, щоб пришвидшити час, потрібний для пошуку заданого маршруту (підвищити продуктивність програми); проте, Ви зможете скористатися цим, лише якщо всі ваші визначені маршрути всередині програми налаштовані за допомогою специфічної для контролера карти.pings (див. Приклад №2 вище).

Давайте виконаємо цю команду, яка згенерує для нас новий контролер.

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

По суті, ця команда генерує заглушку для контролера з назвою «UploadController» в головному каталозі контролера за адресою /app/Http/Controllers/UploadController.php. Можете відкрити цей файл і поглянути. Це дуже просто, оскільки це лише заглушена версія контролера з правильним шляхом простору імен та необхідними класами, з яких він розширюється.

Формування запиту

Перш ніж ми продовжимо цей посібник з PHP Laravel та внесемо кілька змін до згенерованого заглушки UploadController, буде доцільніше спочатку створити клас запиту. Це тому, що метод контролера, який обробляє запит, повинен вказувати тип об'єкта запиту у своєму підписі, що дозволить йому автоматично перевіряти вхідні дані форми (як зазначено в методі rules(); про це пізніше). А поки що давайте знову використаємо команду artisan для генерації нашої заглушки запиту:

php artisan make:request UploadFileRequest

Ця команда згенерує файл з назвою UploadFileRequest всередині app/Http/Requests/UploadFileRequest. Відкрийте заготовку та погляньте. Ви побачите, що він дуже простий, містить лише два методи: authorize() та rules().

Створення логіки перевірки

Давайте змінимо заголовок запиту відповідно до потреб нашої програми. Змініть файл так, щоб він виглядав так:

<?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). Оскільки ми хочемо дозволити користувачеві завантажувати будь-який тип файлу, ми просто дотримуватимемося обмеження перевірки файлів.

Це, мабуть, і все, що стосується об'єкта запиту. Його головне завдання — просто зберігати прийнятний набір критеріїв (обмежень), яким повинні відповідати параметри тіла форми, щоб можна було глибше перейти до застосунку. Ще слід зазначити, що ці два поля (userFile та fileName) також мають бути вказані всередині HTML-коду у вигляді полів введення (з назвою поля, що відповідає назві всередині об'єкта запиту).

Ви можете запитати: це визначає характеристики того, що має містити запит форми, але де саме відбувається перевірка цих обмежень? Ми розглянемо це далі.

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

Відкрийте додаток/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, перегляньте документацію. тутУ наведеному вище випадку ми використовуємо директиву маршруту для генерації URL для надсилання нашої форми.

Пам’ятайте, що ми визначили наші маршрути раніше в застосунку у файлі web.php, вказавши для кожного з них легке для запам’ятовування ім’я. Директива {{route()}} приймає ім’я маршруту, шукає його у внутрішньо кешованому списку маршрутів і генерує повний URL на основі визначення цього маршруту у файлі web.php. У цьому першому випадку ми вказуємо, що хочемо, щоб форма надсилала надіслані дані до /процесу URL нашої програми, яка визначається як POST маршруту.

Наступне, що ви могли помітити, це тег @csrf одразу під тегом відкриття форми. У blade цей тег генерує параметр _token у формі, який перевіряється всередині програми, перш ніж дозволити обробку даних форми. Це гарантує, що дані всередині форми мають дійсне походження, і запобігає атакам підробки міжсайтових запитів. Для отримання додаткової інформації про це див. Документи.

Після цього ми визначаємо нашу форму як звичайну; однак, зверніть увагу, що назви наших параметрів форми, userFile та fileName, є точно такий же як визначено всередині нашого об'єкта запиту. Якщо ми забудемо включити вхідні дані для заданого параметра, який був визначений в об'єкті запиту (або допустимо його неправильне написання), запит не вдасться виконати, і буде повернуто помилку, що запобігатиме потраплянню оригінального запиту форми до методу контролера, розташованого за адресою UploadController@process.

Спробуйте та надішліть кілька файлів до програми за допомогою цієї форми. Після цього перейдіть до /список сторінку, щоб переглянути вміст папки завантажень із завантаженими файлами, переліченими в таблиці:

Bigger Picture

Давайте зробимо крок назад і подивимося, що ми зробили в цьому посібнику з Laravel.

Ця діаграма зображує програму в її поточному стані (без детальної інформації):

Вам слід пам'ятати, що об'єкт запиту, який ми створили на початку цього посібника з Laravel, повинен мати ті ж параметри, визначені в його методі правил, що й у формі в шаблоні blade (якщо ні, перечитайте розділ «Створення логіки перевірки»). Користувач вводить форму на веб-сторінці, яка відображається через механізм шаблонів blade, і надсилає форму. Код jQuery шаблону внизу зупиняє надсилання за замовчуванням (яке автоматично перенаправляє на окрему сторінку), створює ajax-запит, завантажує запит з даними форми та завантаженим файлом, і надсилає все це на перший рівень нашої програми: запит.

Об'єкт запиту заповнюється шляхом пов'язування параметрів усередині методу rules() з надісланими параметрами форми, а потім перевіряє дані відповідно до кожного заданого правила. Якщо всі правила виконано, запит передається до будь-якого методу контролера, що відповідає значенням, визначеним у файлі маршруту web.php. У цьому випадку роботу виконує метод process() UploadController. Після того, як ми звернулися до контролера, ми вже знаємо, що запит пройшов перевірку, тому нам не потрібно повторно перевіряти, чи є задане ім'я файлу справді рядком, чи параметр userFile насправді містить певний тип файлу. Ми можемо продовжити як завжди.

Потім метод контролера отримує перевірені параметри з об'єкта запиту, генерує повне ім'я файлу, об'єднуючи переданий параметр fileName з оригінальним розширенням userFile, зберігає файл у каталозі нашої програми, а потім повертає просту відповідь у форматі JSON, що підтверджує успішність запиту. Відповідь отримує логіка jQuery, яка виконує ще кілька завдань, пов'язаних з інтерфейсом користувача, таких як відображення повідомлення про успіх (або помилку) протягом 5 секунд, потім його приховування, а також очищення попередніх записів форми. Це робиться для того, щоб користувач точно знав, що запит був успішним, і міг завантажити інший файл, якщо забажає.

Також зверніть увагу на діаграму вище, де саме проходить межа між клієнтом і сервером. Ця концепція є абсолютно необхідною для розуміння та допоможе вам вирішити проблеми, які можуть виникнути в майбутньому під час роботи, наприклад, з кількома асинхронними запитами, що можуть виникнути одночасно. Розділення знаходиться прямо на межі об'єкта запиту. Сам об'єкт запиту можна розглядати як «шлюз» до решти програми. Він виконує початкову перевірку та реєстрацію значень форми, переданих з веб-браузера. Якщо вони вважаються дійсними, то вони передаються до контролера. Все до цього знаходиться на фронтенді («клієнт» буквально означає «на комп'ютері користувача»). Відповідь повертається з програми назад на сторону клієнта, де наш код jQuery терпляче чекає на її надходження та виконує кілька простих завдань інтерфейсу користувача після її отримання.

Ми також розглянули багато важливих часто задаваних питань Питання співбесіди, пов’язані з Laravel і PHP для новачків, а також досвідчених кандидатів, щоб отримати потрібну роботу.

Поширені запитання