То есть если я ещё какое-то стороннее решение вкручу в проект композером — оно мне геолокацию затрёт?
Laravel по-русски
Laravel по-русски
То есть если я ещё какое-то стороннее решение вкручу в проект композером — оно мне геолокацию затрёт?
Какими реальными проблемами чревато описанное решение? Особенно если вспомнить, что composer сделал бы именно это?
Как-то не пришло в голову. Если б несколкьо неймспейсов добавлял бы — наверное, так бы и поступил.
И так и сделаю, когда в следующий раз буду что-то добавлять. А сейчас уже оставлю как есть.
Ну да. Раз уж пришлось работать в MVC (мне больше нравится мои собственные паттерны, но что делать — не кормят они...) — то очень поможет порядок: где что искать.
В моделях — ищем работу с базой(-ами).
В контрололерах — всю логику.
В представлениях — всё, что относится к вёрстке.
Птоэтому у меня представления короткие и почти лишенные логики. В них — верстка страницы.
Я поддерживабю проект, написанный другими разработчиками. Там представление — это «ад каннибалов». Вот чего я стараюсь избегать.
У вас все посты совершенно в одном духе — как раньше было хорошо, как сейчас плохо
Да ладно. Ничего подобного в моём комментарии нет.
Какая разница между представлением и логикой, если они пересекаются?
Никакой. От себя добавлю — они всегда пересекаются. Ну кроме каких-то совершенно «учебных» случаев.
Тогда уж писать всё в одном файле, как в WordPress
Я никогда в жизни не агитировал за WordPress.
Это открывает подобные возможности для использования шаблонов:
PHP<ul>
@foreach ($pages as $page)
<li>{{ $loop->iteration }}: {{ $page->title }}
@if ($page->hasChildren())
<ul>
@foreach ($page->children() as $child)
<li>{{ $loop->parent->iteration }}.{{ $loop->iteration }}:
{{ $child->title }}</li>
@endforeach
</ul>
@endif
</li>
@endforeach
</ul>
Зачем таким образом пародировать программный код? Не лучше ли сочинить его в контроллере и кинуть в представление как параметр?
P.S. А я так и знал — не получится в MVC по-человечески разнести логику и оформление.
Спасибо! Я скоро напишу статью, когда закончу часть своего нового проекта.
Как Вы заметили, я не пересказываю документацию своими словами. Я ее читаю, чего-то очень мне в ней не нахожу, бьюсь, как рыба об лед, и если удается «забороть» — пишу, как мне это удалось.
Думаю, про авторизацию напишу. Иду на ошупь, дока совсем не помогает.
Стандартизация — это такая тема, о которой я могу писать до завтрашнего утра. Знаете, как это бывает — любимая тема. Но чтобы поберечь Ваше (да и своё) время, позвольте объяснить, почему я намеренно упускаю ее. Потому что стандартизация в нормальном ее понимании — это результат работы уполномоченного на то органа. Который, прежде чем жахнуть очередной стандарт — хотя бы обсудит его. Ну вот как W3C. А если одна команда зафигачила правила, ни с кем не советуясь — это не стандартизация. Надо искать другое название. Например, нотации Laravel.
Всё, занудство кончилось. Уж простите: я без него не мог. А теперь по существу. Давайте почитаем Ваше прекрасное описание хромой конторы:
Есть компания, у неё раз в N месяцев меняются кадры (пусть даже раз в год). При этом продукт компании имеет цикл жизни N*10. Итого после каждой смены имеем затраты на изучение новым человеком вашего личного велосипеда
То есть компания создать свои нотации не в состоянии. Значит, руководитель разработки назначен поспешно. Ему нужно вернуться на тот уровень, на котором он себя проявил, и понаблюдать за работой хорошего IT-менеджера. Который первое что сделает — составит нотации.
Работа руководителя — не только орать и материться, как ни странно это звучит для многих.
Достаточно ли для команды разработчиков нотаций Laravel-a?
У меня нет и тени сомнений, что нет, недостаточно. Доказательство у меня перед глазами — увы, не могу показать Вам. Не имею права. Я про проект, который принял. Так вот. С вот этим: затраты на изучение новым человеком личного велосипеда — никаких проблем. И не только на мое изучения Ларавела. Но и на то, по каким моделям и таблицам разбросана информация. Благо, незатейливая. Но если что посерьезней — никакой Лаправел не спасет.
Так что признайтесь: Вы явно погорячились, написав: Используя фреймворк — Laravel или любой другой популярный — таких затрат нет в принципе.
Советую переформулировать.
Спасибо за добрый слова. Спешу в меру сил ответить на Ваши вопросы.
Только не ясно для чего он нужен и как он облегчает жизнь
Ну а зачем нужны костыли и как они облегчают жизнь — Вам понятно? Если человека что-то не так с ногой (ногами) — костыли ему очень помогут. Но здоровому человеку без них лучше.
Здесь ровно то же самое. Если ты хромой программист — Laravel тебе поможет. Это лучшие костыли, которые я встречал. Хорошие, удобные, прекрасно настраиваемые костыли.
Я считаю, что нормальный программист нуждается в велосипеде, а не в костылях. Опять же — понятно, как велосипед облегчает жизнь. Я разработал такой велосипед, но заработать на нём не смог — и пошел на наёмную работу. Там надо на Laravel-е делать проект. Делаю. Жить-то надо...
Когда-то в прошлой жизни я занимался наукой (успел даже диссер защитить). И в те годы было четкой разделение: «научная статья» и «научно-популярная статья». Считалось, что когда доводишь научное знание для массового читателя, то допускается для блага этого читателя отступить от строгости. Особенно это касается студентов.
То есть если документации называют то, что передается в Route, замыканиями — то в статье для начинающих (а адресат статьи указан в самом начале) лучше и назвать их замыканиями — чтоб не было совершенной лишней «спотыкачки».
Меня вполне устроит, если человек благодаря моей статье выйдет из паники и начнет работать, не вполне понимая разницу между замыканиями и анонимными функциями.
Скорректировал: добавил к «макету» и «представление». И я не писал о view ( с маленькой буквы) как о функции — я писал о фасаде View (с большой буквы)
Я скорректировал — но не в Вашей редакции, уж простите. Я считаю, что Ваша редакция непонятна новичку.
« и для них запускает вот это замыкание (ну или лямбда-функцию — как больше нравится):»
Видно что вы не понимаете разницу между двумя данными понятиями. Поменять лучше просто на « и для них запускает вот эту анонимную функцию (ну или лямбда-функцию — как больше нравится)»
Есть документация php и документация Laravel. Они анонимные функции называют именно замыканиями:
Anonymous functions, also known as closures
http://php.net/manual/en/functions.anonymous.php
В базовой версии нашего приложения мы определили всю нашу логику в файле routes.php, используя замыкания.
https://laravel.ru/docs/v5/quickstart-intermediate#%D0%BC%D0%B0%D1%80%D1%88%D1%80%D1%83%D1%82%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F
Может, Вы правы, а эти две доки ошибаются (это не ирония!). Но я ошибусь вместе с ними, чтоб помочь новичкам. «Выведи, мой друг, сначала меня из затруднения — а нравоучение ты мне и потом прочтешь» (с) Лафонтен Пусть человек сначала преодолеет отчаяние, наччнет работать — и только потом настанет возможность обсудить с ним отличия анонимных функций от замыканий. А кстати, в чем это отличие?
Что такое view (по-русски «макет»)?
Нет, `view` по-русски всё же `представление` ну или `шаблон` если говорить о самом файле.
Пусть сначала на этом сайте документацию поправят (laravel.ru/docs/v5/views)
Представления (views), они же макеты
Ну не нравится мне слово «представление» — одно в русском языке значение: спеутакль, шоу. Макет — всяко лучше.
Честно скажу: я не понял, как бы Вы попроще сделали. И я пока нигде не нашёл человеческого описания.
Сделал, как сумел — и описал здесь. Работает.