Ellrion ⁺²⁰

Что то аргумент не понятен. Причем тут пивот таблицы и имя контроллера? Можете пояснить, пожалуйста

Видимо я его всё же обидел, так как он удалил не только ту статью, но и свою предыдущую, которую многие посчитали полезной. А жаль, такой цели у меня не было.

Спасибо за исправления. Да с грамматикой у меня всегда было плохо. Надо будет давать кому то вычитывать сначала, если буду еще писать.

Как разворачивать приложение т.е. composer install? Ваше решение затрется. При добавлении вендора по идее тоже? И при обновлении (composer update). Как вы деплоете? У вас вендорная директория под гитом что ли? Или вы гитом вообще не пользуетесь.

Так делать нельзя не в коем случае. Или форум с подменой репозитория. Или уж если не так то на худой конец прописать автолоудинг в composer.json

Что касается первой части вы абсолютно не правы. Во всей литературе именно V из MVC на русском переводят как представление и реже вид. А конкретный файл это шаблон.
Про второй тоже. Но тут писать больше, а я с телефона сейчас. Отмечу только Что касается пыхи с 5.4 и this, то остались статические анонимки.
Я что то устал тут приператься. Жаль что тут не хабр и нас некому рассудить.

1. «Выполнит ли статья эту миссию, если вместо «Роуты ловят» написать: ...»

Ну зачем передергивать. Можно писать просто но при этом без теоритических ошибок. И статья выполнит миссию если написать вместо «этот фасад ловит запросы» — «И роут указывает где нужно обработать запрос с определенным методом на определенный урл....»

К документации на данном сайте я отношения не имею. Но термин `представление` нравится или нет является устоявшимся когда мы говорим о слое View из MVC. Не нравится он, ну можно использовать `Вид` еще. И соответственно класс View или View\Factory или фасад View это все представление. А вот файлики содержащие разметку ну можно назвать и представление и вид и шаблон, ну да и макет на худой конец. Но там в контексте ты писал о view как о функции и она вот не разу все же не макет а часть функционала слоя представления.

А про существование такой команды или описание каждого variable из окружения ты где узнаешь? в доке? так зачем порождать лишнюю сущность, смотри там расположение роут файла\файлов.

Давайте по порядку.

1. "Все запросы пользователя перенаправляются на файл КаталогПроекта/public/index.php. Скорее всего, это перенаправление осуществляется согласно файлу КаталогПроекта/public/.htaccess. Может, и не .htaccess, а как-то иначе, "

Уже или бы вычеркнули этот текст или писали нормально, что во первых вебсервер должен быть настроен так, что рутовая дериктория это publick (т. е. для apache это `ServerRoot` а для nginx `root `) Ну а дальше уже для apache отработает реврайт из .htacess для так называемых 'Pretty URLs', т. е. все обращения к несуществующим деректориям и файлам перенаправляются на index.php. В случае с nginx такое правило нужно писать в настройках вебсервера. (Ну эту часть статьи за ошибку не считаю, просто не качественно)

1. « но важно понять суть: http-запрос пользователя со всем своим фаршем ($_GET, $_POST, $_COOKIE, $_FILES, $_SERVER) валится на КаталогПроекта/public/index.php.»

Тут высказывание не корректно, так как запрос это заголовки и тело, а то что php инициализирует при создании процесса суперглобалы (в которые помещает данные запроса, если таковые есть или просто имеет их пустыми) так это тут не причем. Т. е. просто уберите упоминание суперглобалов из фразы. (тоже не критично но читать не приятно).

1. «Route — это не класс. Это фасад. Пока не пытайся это осмыслить — уясни то, что нужно понять сейчас: этот фасад ловит запросы (в данном случае — пришедшие методом GET в корень сайта) и для них запускает вот это замыкание (ну или лямбда-функцию — как больше нравится):»

Route действительно фасад, но классом это ему быть не мешает. И уж точно неправильно говорить что он «ловит запросы». Это не так. Данная конструкция регистрирует роут, т. е. добавляет в список роутов еще одну запись. Запись это по сути соответсвие между шаблоном строки запроса и кодом который данный запрос будет обрабатывать. Запрос же «ловится» (т. е. генерируется экземпляр класса запроса, из данных пришедшего http запроса) при создании инстанса приложения в старых версиях (https:github.com/laravel/framework/blob/4.2/src/Illuminate/Foundation/Application.php#L111) или же мы создаем его явно и передаем в метод приложения handle (https:github.com/laravel/laravel/blob/v5.3.16/public/index.php#L53). А уже потом среди роутов подбирается тот который нужен для обработки запроса.

1. «Что такое view (по-русски «макет»)?»

Нет, `view` по-русски всё же `представление` ну или `шаблон` если говорить о самом файле.

1. «Где они лежат? Опять же — прояви смекалку.»

Где они лежат четко и ясно написано в документации.

1. « и для них запускает вот это замыкание (ну или лямбда-функцию — как больше нравится):»

Видно что вы не понимаете разницу между двумя данными понятиями. Поменять лучше просто на « и для них запускает вот эту анонимную функцию (ну или лямбда-функцию — как больше нравится)»

1. «Как видишь, и так можно замыкание записать:»

Туда же. Так записать можно не замыкание а обработчик для данного роута.

1. «Обратите внимание: закрыть тег php я не забыл. Это так надо.»

Убери это. Или уж если акцентируешь внимание, то напиши кому и зачем это надо. Или что без закрывающего тега не будет работать? Будет конечно, просто это стандартная практика для php и часть psr-2

1. «Краткий комментарий к нашему контроллеру: он по своей логике сгенерил переменную $hw и с именем hw передал ее фасаду, который будет из view (с именем hw) делать то, что увидит пользователь в браузере.»

нет, контроллер ничего не передавал фасаду. Тут используя фасад View идет создание экземпляра представления (если не вдаваться в подробности и не писать о том что по сути фасад передает вызов метода make в \Illuminate\View\Factory). Так вот а непосредственно переменная в это представление передается. и контроллер возвращает объект представления (\Illuminate\View\View). а уже потом он приложением рендерится и преобразуется в ответ (responce).
Т.е. даже имя контроллера renderHW не корректно.

Вот собственно. стал мир лучше?

К сожалению в статье достаточно много неправильной терминологии и теоретических ошибок.