| Laravel по-русски

Статистика: Символов — 1 652/1 372 без пробелов (1 509/1 256 без кода):, слов — 254
Разметка: Markdown
Спасибо за Ваше мнение! Но сложилось ощущение, что слово 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? 

П.С. Я тут встречал достаточно много споров что лучше - в контроллере получить общие данные и передать их в вид, в котором прописать всю логику, или прописать логику в контроллере, а в вид передать уже готовые данные. Лично я выбрал второй вариант - виды становятся чище и понятнее. А чтобы контроллеры не раздувались, логику выносить на уровень сервисов. И это опять же не предмет для холивара. Кому как удобнее. Кроме того, простые виды проще в сопровождении для собственников сайта.