Какой еще возраст?)) Как говорил мой первый босс «программирование, это занятие для молодых, и дело тут не в возрасте» ))
Laravel по-русски
Laravel по-русски
Какой еще возраст?)) Как говорил мой первый босс «программирование, это занятие для молодых, и дело тут не в возрасте» ))
Минус? Я никогда никому нигде не ставлю минусов, это принцип. Считаю, что минус — это как нагадить изподтишка. Не моё.
Так Вы Сергей Ш?
Уважуха Вам, я ж и сам из MODX, и даже какие-то Ваши пакеты юзал, или советы применял.
Сейчас случайно на Ваш пост наткнулся по этой теме, что выше, ищу, почему в MODX сессии не передаются :-) Вынужден поддерживать сайт на MODX по работе.
Успехов Вам в Laravel! :-)
Думаю, не стоит в Laravel тащить MODX-овые подходы и изобретать велосипеды :-) Наверное, именно поэтому они там, в MODX, прикручивают шаблонизатор. И MVC Ваш пример противоречит, а в Laravel это соблюдают железно.
А так можете, в шаблоне:
@include('любой_маленький_виджет')
Спасибо за Ваше мнение! Но сложилось ощущение, что слово MODX явилось главным мотивом ответа. К Laravel тоже прикручивают и Doctrine и Twig. Это показатель чего? Так что давайте без холиваров.
По поводу MVC вопрос опять же спорный. Да и не понятно, причём здесь MVC. Представьте, что вы вместо view('название вида') вызываете view_raw('HTML строка'). В чём принципиальное отличие? Про @include пример вообще не по теме.
Что касается моего примера, то я сразу оговорился, что он чисто для демонстрации. Вот ещё пример подхода из одной очень популярной админки
// View
<div class="links-row" {!! $attributes !!}>
@foreach($links as $link)
{!! $link->render() !!}
@endforeach
</div>
Ссылка - это класс, у которой прописан вид и метод render() просто его возвращает
return view('_partial.li', ['item', $item])->render();
Почему бы вместо файла сюда не подсунуть строку с кодом? Вот для таких случаев и пригодится мой вариант. Я так и написал, что это нужно не всем и не всегда.
Да, можно сделать один вид и в нём зафигачить логику для всех вариантов - для обычного пункта, для активного, для имеющего подпункты, для неимеющего. Если следовать задаче упростить вид, то нужно 4 вида. Что плохого, чтобы вместо 4 файлов использовать 4 свойства в классе с шаблонами HTML?
П.С. Я тут встречал достаточно много споров что лучше - в контроллере получить общие данные и передать их в вид, в котором прописать всю логику, или прописать логику в контроллере, а в вид передать уже готовые данные. Лично я выбрал второй вариант - виды становятся чище и понятнее. А чтобы контроллеры не раздувались, логику выносить на уровень сервисов. И это опять же не предмет для холивара. Кому как удобнее. Кроме того, простые виды проще в сопровождении для собственников сайта.
- Туда и клади свои контроллеры, называя файл Контроллер.php
shphp artisan make:controller PhotoController
Он тогда сам все создаст в нужной папке, можно даже уже с каркасом методов.
Аналогично, список (расширенный!) всех маршрутов:
shphp artisan route:list
← Назад | Дальше → Движется на Habravel
Тогда сорри. Но я к этому спокойно отношусь. Возраст :)