Учебник по Laravel для начинающих

Что такое Laravel?

Laravel — это веб-фреймворк MVC с открытым исходным кодом для PHP. Laravel — это надежная среда, обеспечивающая легкую разработку веб-приложений PHP с такими функциями, как модульная система упаковки со специальным менеджером зависимостей, доступ к реляционным базам данных и другие утилиты для развертывания и обслуживания приложений.

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

Почему Ларавел?

Около 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:

• приложение/ : Это папка с исходным кодом, где находится код нашего приложения. Все контроллеры, политики и модели находятся внутри этой папки.
• начальная загрузка/: Содержит скрипт запуска приложения и несколько файлов сопоставления классов.
• конфигурация/: Содержит конфигурационные файлы приложения. Обычно они не изменяются напрямую, а полагаются на значения, заданные в файле .env (окружение) в корне приложения.
• база данных/ : Здесь хранятся файлы базы данных, включая миграции, начальные значения и тестовые фабрики.
• общественный/ : Общедоступная папка, содержащая скомпилированные ресурсы и, конечно же, файл index.php.
• Ресурсы/ : Содержит внешние ресурсы, такие как 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. Эти маршруты не имеют состояния и не используют сессии или межзапросную память (один запрос не разделяет данные или память с другими запросами; каждый из них самоинкапсулирован).
• console.php: эти маршруты соответствуют пользовательским командам Artisan, которые вы создали для своего приложения.
• channels.php: регистрирует маршруты для трансляции событий.

В данный момент ключевой файл, на который следует обратить внимание, — это файл web.php, специфичный для каждого браузера. В нём уже определён один маршрут по умолчанию, который вы используете при переходе в корневую директорию вашего приложения (корневая директория находится в каталоге public). Для корректной работы нашего приложения для загрузки файлов нам понадобятся три разных маршрута:

• /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» (Модель-Представление-Контроллер), на которой основан 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 должен быть включен в тело формы (т.е. обязателен) и используется в качестве имени файла, под которым мы будем хранить файл в хранилище (это делается в контроллере; мы вернемся к этому чуть позже). Мы также указываем, что имя файла должно быть строкой, добавляя символ вертикальной черты (|) и слово «string». Ограничения всегда разделяются вертикальной чертой, что позволяет указывать любые дополнительные критерии для данного поля в одной строке.

Второй параметр, 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 в качестве первого аргумента и имя файла для его сохранения в качестве второго.
• Возвращает JSON-ответ, указывающий на успешное выполнение запроса.

Шаблон клинка

Последней важной частью этой головоломки является шаблон лезвия, который будет содержать все 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>

Вот что наш /загрузить страница выглядит так:

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

Напомним, что ранее в приложении в файле web.php мы определили маршруты, указав для каждого из них легко запоминающееся имя. Директива {{route()}} принимает имя маршрута, ищет его во внутреннем кэшированном списке маршрутов и генерирует полный маршрут. URL на основе определения этого маршрута в файле web.php. В первом случае мы указываем, что хотим, чтобы форма отправляла отправленные данные на адрес /process. URL нашего приложения, которое определяется как POST маршрута.

Следующее, что вы могли заметить, — это тег `@csrf`, расположенный непосредственно под открывающим тегом формы. В Blade этот тег генерирует параметр `_token` в форме, который проверяется внутри приложения перед обработкой данных формы. Это гарантирует, что данные в форме имеют допустимое происхождение, и предотвращает атаки типа межсайтовой подделки запросов (XSS). Для получения дополнительной информации об этом см. Документы.

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

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

Больше фото

Давайте сделаем шаг назад и посмотрим, что мы сделали в этом уроке по Laravel.

На этой диаграмме показано текущее состояние приложения (без учета общих деталей):

Следует помнить, что объект запроса, созданный в начале этого руководства по Laravel, должен иметь те же параметры, определенные в его методе rules, что и параметры формы в шаблоне Blade (если это не так, перечитайте раздел «Создание логики валидации»). Пользователь заполняет форму на веб-странице, которая отображается с помощью шаблонизатора Blade, и отправляет форму. Код jQuery в нижней части шаблона предотвращает отправку по умолчанию (которая автоматически перенаправит на отдельную страницу), создает AJAX-запрос, загружает запрос с данными формы и загруженным файлом и отправляет все это в первый слой нашего приложения: в сам запрос.

Объект запроса заполняется путем сопоставления параметров метода rules() с параметрами отправленной формы, после чего данные проверяются в соответствии с каждым указанным правилом. Если все правила соблюдены, запрос передается в соответствующий метод контроллера, заданный в файле маршрутизации web.php. В данном случае это метод process() контроллера UploadController. Как только запрос попадает в контроллер, мы уже знаем, что он прошел проверку, поэтому нам не нужно повторно проверять, является ли указанное имя файла строкой или параметр userFile содержит какой-либо тип файла. Мы можем продолжить работу в обычном режиме.

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

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

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

Часто задаваемые вопросы (FAQ)