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

Что такое Laravel?

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

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

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

Около 2000 года, большинство Коды PHP был процедурным и его можно было найти в форме «скриптов», которые представляли собой запутанную путаницу спагетти-кода. Даже самые простые страницы не имели разделение интересов, и поэтому приложению было довольно легко быстро превратиться в кошмар обслуживания. Миру нужно было что-то лучшее… Введите PHP версии 5 и множество PHP-фреймворков, пытающихся обеспечить столь необходимое разрешение и лучшие решения различных проблем веб-приложений.

С тех пор мы видели множество выпущенных фреймворков, которые проложили путь к популярным фреймворкам, существующим и используемым сегодня. Сегодня в тройку лидеров (по нашему мнению) входят Zend Framework, Symfony и, конечно же, Laravel. Хотя каждая из этих платформ основана на схожих принципах и направлена на решение (в основном) одних и тех же общих проблем, их ключевые различия заключаются в их реализации. У каждого из них есть свои особенности решения проблем. Когда вы посмотрите на код, созданный каждым из них, вы увидите, что их друг от друга отделяет довольно сплошная линия. По нашему скромному мнению, фреймворк Laravel — лучший.

Узнать больше о Разница между Laravel и CodeIgniter

Как скачать и установить Laravel с помощью Composer

ЗАМЕТКА Предполагается, что в вашей локальной системе уже установлена копия PHP. Если нет, вы можете прочитать, как его установить. здесь

Composer — это одновременно менеджер пакетов и зависимостей. Чтобы установить его, откройте терминал и перейдите в новый каталог. Запустите эту команду:

curl -Ss getcomposer.org/installer | php

Результаты этой команды будут выглядеть так:

Внимание Более подробные инструкции по настройке Laravel можно найти в документации Laravel. здесь.

Вы увидите, как он загружает и компилирует скрипт композитора.phar, который мы используем для установки Laravel. Хотя существует множество способов настроить новое приложение Laravel, мы сделаем это с помощью скрипта композитора Laravel. Чтобы установить этот скрипт, запустите:

composer global require laravel/installer

Это будет выглядеть примерно так:

При этом будут загружены и установлены все файлы фреймворка, а также все необходимые зависимости. Пакеты будут сохранены в каталоге поставщика. После того, как он загружен и установлен, это так же просто, как ввести следующую команду:

laravel new uploadApp

Вы увидите что-то вроде следующего вывода:

Composer устанавливает все пакеты, необходимые Laravel для работы. Это может занять несколько минут, так что наберитесь терпения. После завершения запустите команду ls -al, чтобы посмотреть, что было установлено.

Вот краткое описание каталогов в обычном приложении Laravel:

приложение/ : Это исходная папка, в которой находится код нашего приложения. Все контроллеры, политики и модели находятся в этой папке.
начальная загрузка/: Содержит сценарий запуска приложения и несколько файлов карты классов.
конфигурация/: Содержит файлы конфигурации приложения. Обычно они не изменяются напрямую, а вместо этого полагаются на значения, установленные в файле .env (среды) в корне приложения.
база данных/ : Содержит файлы базы данных, включая миграции, начальные значения и тестовые фабрики.
общественный/ : Общедоступная папка, содержащая скомпилированные ресурсы и, конечно же, файл index.php.
Ресурсы/ : Содержит внешние ресурсы, такие как файлы JavaScript, языковые файлы, файлы CSS/SASS и все шаблоны, используемые в приложении (называемые шаблонами блейдов).
маршруты/ : Все маршруты в приложении находятся здесь. Существует несколько различных «областей действия» маршрутов, но мы сосредоточимся на файле web.php.
хранилище/ : Все файлы временного кэша, используемые приложением, файлы сеансов, скомпилированные сценарии представления и файлы журналов.
тесты/ : Содержит тестовые файлы для приложения, такие как модульные тесты и функциональные тесты.
продавец/ : Все пакеты зависимостей, установленные с помощью композитора

Теперь давайте создадим остальную часть приложения и запустим его с помощью специальной ремесленной команды (чтобы избавить себя от необходимости устанавливать и настраивать веб-сервер, такой как Apache или nginx). Файл .env содержит все значения конфигурации, которые файлы в каталоге /config используют для настройки приложения. Внутри него вы заметите значения конфигурации для различных параметров, используемых внутренними компонентами приложения.

Дизайн приложения: краткое изложение наших требований

В этом онлайн-уроке по Laravel мы создадим очень простое приложение, которое будет делать только две вещи:

обрабатывать загрузку файлов из веб-формы
отображение ранее загруженных файлов на другой странице.

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

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

A маршрут это позволит внешнему миру (Интернету) использовать приложение, а также укажет конечную точку, которая будет указывать, где находится логика сохранения загруженного файла.
A контроллер который обрабатывает поток запроса и ответа
A шаблон который будет использоваться для отображения списка ранее загруженных файлов и самой формы загрузки.
A запросить который контроллер будет использовать для проверки данных, переданных из веб-формы

Что такое маршрут?

Маршрут в Laravel — это, по сути, конечная точка, определяемая URI, который действует как «указатель» на некоторую часть функциональности, предлагаемой приложением. Чаще всего маршрут просто указывает на метод на контроллере, а также определяет, какие методы HTTP могут обращаться к этому URI. Маршрут также не всегда означает метод контроллера; он также может просто передать выполнение приложения определенной функции Closure или анонимной функции.

Зачем использовать Маршрут?

Маршруты хранятся в файлах в папке /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(), которая принимает в качестве аргумента одну строку и используется для более или менее «маркировки» конкретного маршрута легко запоминающимся именем (в наших случаях загрузить, обработать и составить список). Я понимаю, что не так уж и здорово давать каждому маршруту собственное имя, когда URL-адрес имеет одно и то же имя, но это действительно удобно, когда у вас есть определенный маршрут, например /users/profile/dashboard/config, который будет легче запомнить как профиль-администратора или пользователя-конфигурации.

Примечание о фасадах:

Фасады предоставляют «статический» интерфейс для классов, доступных в сервисном контейнере приложения».
Они предоставляют краткий, запоминающийся синтаксис, который позволяет вам использовать функции Laravel, не запоминая длинные имена классов, которые необходимо вводить или настраивать вручную.

В приведенных выше определениях маршрутов в этом руководстве по платформе Laravel мы используем фасад Route вместо того, чтобы вручную создавать экземпляр нового объекта Illuminate/Routing/Router и вызывать соответствующие методы для этого объекта. Это просто ярлык, который позволяет экономить на вводе текста. Фасады широко используются во всей среде 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: определение маршрута находится внутри маршрутов/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» внутри контроллера. of с определением маршрута как функции обратного вызова:

Наша логика четко выделена в отдельный класс (разделение задач).
Наш контроллер будет настроен для расширения позже, если нам понадобится добавить к нему дополнительные возможности… Скажем, возможно, мы хотели добавить функцию «прощай, мир»… В этом случае мы бы переименовали контроллер в более общий «HelloController», а затем определили два отдельных метода, Привет() и до свидания(). Нам также потребуется определить два отдельных маршрута, которые отображают /привет и / до свидания URI для соответствующего метода на контроллере. Это желательно по сравнению с заполнением файла маршрутов, в котором реализация каждого маршрута определяется как функции обратного вызова.
Laravel имеет встроенную возможность кэшировать все определения маршрутов в приложении, что ускоряет время поиска заданного маршрута (повышает производительность приложения); Тем не менее, вы сможете воспользоваться этим только в том случае, если все ваши определенные маршруты внутри приложения настроены с использованием сопоставлений, специфичных для контроллера (см. Пример № 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. Откройте заглушку и посмотрите... Вы увидите, что это очень просто, содержит всего два метода: авторизация() и правила.

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

Давайте изменим заглушку запроса в соответствии с потребностями нашего приложения. Измените файл так, чтобы он выглядел так:

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

Изменений не так много, но обратите внимание, что метод авторизации() теперь возвращает 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 и имя файла) также должны быть указаны внутри 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 store(UploadFileRequest $request)
   {
       //At this point, the parameters passed into the $request (from form) are
       //valid--they satisfy each of the conditions inside the rules() method

       $filename = $request->fileName;    //parameters have already been validated
       $file = $request->file('userFile'); //that we don't need any additional isset()

       $extension = $file->getClientOriginalExtension(); //grab the file extension
       $saveAs = $filename . "." . $extension; //filename to save file under

       $file->storeAs('uploads', $saveAs, 'local'); //save the file to local folder

       return response()->json(['success' => true]); //return a success message
   }
}

Так что это довольно простой способ сохранить загруженные файлы на диск. Вот разбивка метода upload() выше:

Введите подсказку о классе запроса в методе контроллера, который выполняет функцию «мясо и картошка», чтобы мы могли автоматически проверять входящие данные.
Извлеките файл из (теперь проверенного) объекта запроса внутри метода контроллера (в данном случае мы назвали его upload(), но ему также можно было бы дать более стандартизированное имя, например store()).
Возьмите имя файла из запроса
Создайте окончательное имя файла, которое будет использоваться для сохранения файла. Метод getClientOriginalExtension() просто получает исходное расширение загруженного файла.
Сохраните файл в локальной файловой системе, используя его метод storeAs(), передав именованный путь внутри каталога /storage в качестве первого аргумента и имя файла для его сохранения в качестве второго.
Вернуть ответ JSON, указывающий, что запрос был успешным.

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

Последней важной частью этой головоломки является шаблон лезвия, который будет содержать весь HTML, CSS и JavaScript для нашего простого приложения. Вот код. Мы объясним его позже.

<body>
   <h1>Upload a file</h1>
   <form id="uploadForm" name="uploadForm" action="{{route('upload')}}" enctype="multipart/form-data">
       @csrf
       <label for="fileName">File Name:</label>
       <input type="text" name="fileName" id="fileName" required /><br />
       <label for="userFile">Select a File</label>
       <input type="file" name="userFile" id="userFile" required />
       <button type="submit" name="submit">Submit</button>
   </form>
   <h2 id="success" style="color:green;display:none">Successfully uploaded file</h2>
   <h2 id="error" style="color:red;display:none">Error Submitting File</h2>
   <script src="//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>
   <script>
        $('#uploadForm').on('submit', function(e) {
            e.preventDefault();
            var form = $(this);
            var url = form.attr('action');
            $.ajax({
                url: url,
                type: "POST",
                data: new FormData(this),
                processData: false,
                contentType: false,
                dataType: "JSON",
                success: function(data) {
                    $("#fileName").val("");
                    $("#userFile").val("");
                }
            }).done(function() {
                $('#success').css('display', 'block');
                window.setTimeout(()=>($("#success").css('display', 'none')), 5000);
            }).fail(function() {
                $('#error').css('display', 'block');
                window.setTimeout(()=>($("#error").css('display', 'none')), 5000);
            });
        });
   </script>
</body>
</html>

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

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

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

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

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

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

Больше фото

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

На этой диаграмме показано приложение в его нынешнем виде (за исключением деталей высокого уровня):

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

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

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

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

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