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

Какво е Laravel?

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

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

Защо Laravel?

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

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

Научете повече за Разлика между Laravel и CodeIgniter

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

ЗАБЕЛЕЖКА Предполага се, че вече имате инсталирано копие на PHP на вашата локална система. Ако не, можете да прочетете как да го инсталирате тук

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

curl -Ss getcomposer.org/installer | php

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

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

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

composer global require laravel/installer

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

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

laravel new uploadApp

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

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

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

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

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

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

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

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

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

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

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

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

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

Защо да използвате Route?

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

web.php Публичните маршрути, базирани на „браузър“. Това са най-често срещаните и това е, което се удря от уеб браузъра. Те преминават през групата на уеб мидълуера и също така съдържат съоръжения за csrf защита (което помага за защита срещу базирани на формуляри злонамерени атаки и хакове) и обикновено съдържат известна степен на „състояние“ (с това имам предвид, че използват сесии)
api.php Маршрути, които съответстват на API група и по този начин имат API мидълуер, активиран по подразбиране. Тези маршрути са без състояние и нямат сесии или памет за кръстосани заявки (една заявка не споделя данни или памет с друга заявка – всяка от тях е самокапсулирана).
console.php Тези маршрути съответстват на персонализирани занаятчийски команди, които сте създали за вашето приложение
channels.php Регистрира маршрути за излъчване на събития

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

/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, за всеки желан маршрут, ние ще го посочим изрично във файла с маршрути 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, което би било по-лесно да се запомни като profile-admin или user-config.

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

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

Горните дефиниции на маршрути в този урок за рамка на Laravel, ние използваме фасадата на Route вместо ръчно инстанциране на нов обект Illuminate/Routing/Router и извикване на съответните методи на този обект. Това е просто пряк път, който спестява писане. Фасадите се използват силно в рамките на 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);
   }
}

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

Нашата логика е ясно разделена в свой собствен клас (разделяне на загрижеността)
Нашият контролер е настроен за разширение по-късно, ако трябва да добавим допълнителни възможности към него… Да кажем, че може би сме искали да добавим функция „сбогом свят“… В този случай бихме преименували контролера на по-общ „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. Отворете мъничето и надникнете... Ще го намерите много просто, съдържащо само два метода, 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 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 като 1-ви аргумент и името на файла, под който да го запишете, като втори.
Връща 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')}}. В острието това е известно като a Директива. Директивата е просто фантастично име за функция – това са функции, специфични за шаблони на блейд, които изпълняват различни операции, които са общи за конструиране на уеб страници и уеб приложения. За по-добро разбиране на всички готини неща, които може да направи блейдът, вижте документите тук. В случая по-горе ние използваме директивата за маршрут, за да генерираме URL адрес за изпращане на нашия формуляр.

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

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

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

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

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

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

Тази диаграма изобразява приложението, както е в момента (с изключение на подробности от високо ниво):

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

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

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

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

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