Laravel по-русски
Laravel по-русски
Обещаю, что не оставлю Ваш труд без внимания. Мне нужно поработать по каждому из пунктов. А сейчас я прошу понять, зачем писалась статья. Какова её миссия.
Я хотел бросить спасательный круг тем, кто не может начать работу с Laravel. Вот как я :)
Читаешь — и приходишь в отчаяние. Я сумел разобраться — и когда разбирался, мне нехватало именно такой статьи — где написано коротко и тупо, НО! после прочтения человек может начать работать.
Где-то, может, нарушена строгость изложения — но дело…
Мне бы она была не лишней. Но раз ее нет — я просто предлагаю два варианта расположения — где можно поискать. Не удивлюсь, если есть и третий, и четвертый.
Ох, не знаете Вы, какие города бывают.
О городе, где я осваиваю Laravel, Вы наверняка много слышали, причем 99% из того, что слышали — полная фигня. Но как в нём нанимают сотрудников — это нечто. Я б и сам не поверил, если б не столкнулся сам.
А до этого знакомства рассуждал также, как Вы. Думал, все будет как в Первопрестолькной, только труба пониже и дым пожиже.
Это не то, что я имел ввиду под «узнать точно». Я бы ожидал что-то вроде phpinfo() в php и show variables в MySQL
Пока могу сказать только, что это интернет-магазин. В офисе: мой фриланс совсем сдулся. Пришлось искать работу.
Не хочу зря пугать, сколько времени искал работу. Все дело в городе, в который занесла судьба. Это город такой — в других городах все куда веселее, а уж в Москве и совсем весело (было, по крайней мере).
Работа от города не зависит, если английский на приемлемом уровне. Недавно на форуме обсуждали как раз это.
Рад, что Вы оценили: я изложил как раз то, чего мне так не хватало в документации и статьях. Я успел дойти до отчаяния, пока не понял то, что написал в этой статье. думал, не смогу в Laravel работать. Но вот уже работаю.
- "Все запросы пользователя перенаправляются на файл КаталогПроекта/public/index.php. Скорее всего, это перенаправление осуществляется согласно файлу КаталогПроекта/public/.htaccess. Может, и не .htaccess, а как-то иначе, "
Уже или бы вычеркнули этот текст или писали нормально, что во первых вебсервер должен быть настроен так, что рутовая дериктория это publick (т. е. для apache это `ServerRoot` а для nginx `root `) Ну а дальше уже для apache отработает реврайт из .htacess для так называемых 'Pretty URLs', т. е. все обращения к несуществующим деректориям и файлам перенаправляются на index.php. В случае с nginx такое правило нужно писать в настройках вебсервера. (Ну эту часть статьи за ошибку не считаю, просто не качественно)
- « но важно понять суть: http-запрос пользователя со всем своим фаршем ($_GET, $_POST, $_COOKIE, $_FILES, $_SERVER) валится на КаталогПроекта/public/index.php.»
Тут высказывание не корректно, так как запрос это заголовки и тело, а то что php инициализирует при создании процесса суперглобалы (в которые помещает данные запроса, если таковые есть или просто имеет их пустыми) так это тут не причем. Т. е. просто уберите упоминание суперглобалов из фразы. (тоже не критично но читать не приятно).
- «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). А уже потом среди роутов подбирается тот который нужен для обработки запроса.
- «Что такое view (по-русски «макет»)?»
Нет, `view` по-русски всё же `представление` ну или `шаблон` если говорить о самом файле.
- «Где они лежат? Опять же — прояви смекалку.»
Где они лежат четко и ясно написано в документации.
- « и для них запускает вот это замыкание (ну или лямбда-функцию — как больше нравится):»
Видно что вы не понимаете разницу между двумя данными понятиями. Поменять лучше просто на « и для них запускает вот эту анонимную функцию (ну или лямбда-функцию — как больше нравится)»
- «Как видишь, и так можно замыкание записать:»
Туда же. Так записать можно не замыкание а обработчик для данного роута.
- «Обратите внимание: закрыть тег php я не забыл. Это так надо.»
Убери это. Или уж если акцентируешь внимание, то напиши кому и зачем это надо. Или что без закрывающего тега не будет работать? Будет конечно, просто это стандартная практика для php и часть psr-2
- «Краткий комментарий к нашему контроллеру: он по своей логике сгенерил переменную $hw и с именем hw передал ее фасаду, который будет из view (с именем hw) делать то, что увидит пользователь в браузере.»
нет, контроллер ничего не передавал фасаду. Тут используя фасад View идет создание экземпляра представления (если не вдаваться в подробности и не писать о том что по сути фасад передает вызов метода make в \Illuminate\View\Factory). Так вот а непосредственно переменная в это представление передается. и контроллер возвращает объект представления (\Illuminate\View\View). а уже потом он приложением рендерится и преобразуется в ответ (responce).
Т.е. даже имя контроллера renderHW не корректно.
← Назад | Дальше → Движется на Habravel
Ну зачем передергивать. Можно писать просто но при этом без теоритических ошибок. И статья выполнит миссию если написать вместо «этот фасад ловит запросы» — «И роут указывает где нужно обработать запрос с определенным методом на определенный урл....»