Laravel по-русски
Laravel по-русски
Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Страницы 1
Возник вопрос как лучше в ларавеле разнести шаблоны от данных, очень хочется услышать ваше мнение!
Рассмотрим очень простую ситуацию, вывод меню или вывод списка новостей, этот список может меняться как сортировкой, так и накладываться фильтр.
Существует 3 ситуации:
1) Разные шаблоны, Одинаковые данные
2) Одинаковый шаблон, Разные данные
3) Разный шаблоны, Разные данные
Для 1 ситуацию отлично подходят композиторы, здесь никаких вопросов нет
2 и 3 ситуации в принципе можно объединить, но что с ними делать?, писать свой класс, например widget, или делать что-то другое
Буду очень признателен, если кто-то поделится личным опытом или за дельные ссылки на статьи!
Не в сети
Мастер 
- Разный шаблоны, Разные данные
Разные шаблоны, разные данные → разные шаблоны, разве нет? Если вопрос в том, как избежать дублирования кода, который подготавливает данные для разных шаблонов — ответ тот же: составители (composers). Можно ведь вынести общую логику для разных шаблонов и описать её всего один раз, а логику, которая отличается — вынести в отдельные составители.
View::composer(array('tpl1', 'tpl2'), function ($view) {
// составитель для обоих шаблонов
});
View::composer('tpl1', function ($view) {
// составитель только для шаблона tpl1
});
Не в сети
Нет, не совсем так
Опишу более конкретный пример, что я понимаю под разными данными и одинаковыми шаблонами
Есть список чего либо, допустим публикаций, шаблон вывода на всех страницах одинаковый, но на одной странице выводится список отсортированный по дате, на другой топ публикаций (отсортированный по рейтингу), на третей еще что-либо, вот здесь как раз и не подходят композиторы.
Не в сети
Мастер
- вот здесь как раз и не подходят композиторы.
Почему не подходят? Шаблон по сути один — вывод списка публикаций. Разница в сортировке. На что это влияет при выводе? Если у списка есть форма-фильтр и там нужно показывать сортировку — это можно вынести в отдельный шаблон и @include его в основной шаблон со списком.
Даже если топ статей выводится в совсем другой разметке, то логически это всё тот же список статей. Можно этот шаблон вынести в отдельный, а не совмещать с простым отсортированным списком публикаций (субъективно зависит от того, насколько разная там разметка), но по-прежнему использовать один и тот же составитель для обоих шаблонов — ведь $view->postList (условно) одинаковые и там, и там.
Не в сети
View::composer('widgets.menu', function($view) {
$list = Page::where('active', '=', 1)->get();
$view->with(array(
'list' => $list,
));
});На одной странице мне нужно вывести все активные страницы (см. выше)
А на другой странице мне нужно вывести все НЕ активные страницы, но при этом шаблон тот-же "widgets.menu"
Можно перед подключением шаблона добавлять логику выборки данных, а потом эти данные передавать в шаблон,
что то типа такого
$list = Page::where('active', '=', 1)->get();
@include('widgets.menu', array('list' => $list))но это примитивно.
К тому же эта логика может понадобиться в другом месте (на нескольких страницах)
Поэтому у меня и возникает вопрос - куда определить "логику выборки данных" что бы ее можно было использовать в нескольких местах без копипаста, может есть какие-нибудь стандартные средства или же здесь лучше писать свой класс Widget'ов
В идеале хочется сократить дублирование кода, т.е. использовать одни и те же шаблоны несколько раз и использовать логику выборки данных несколько раз.
PS условия active = 1 и active != 1 я привел в качестве примера, на деле условия выборки в разы сложнее
Не в сети
Мастер
- но это примитивно.
Не ищите сложных путей там, где можно пройти пешком. PHP по-прежнему позволяет писать «простые» функции-helpers, «простые» классы (то есть не модели, не контроллеры, не составители, не что-то ещё из Laravel), «простые» методы (не getters, не morphers, не пр.). Опять же, есть вариант Wide со scopes. На мой взгляд — если шаблон по сути универсальный, то есть выводит логически одни и те же исходные данные в одинаковой разметке (которую можно затем стилизовать разным CSS, кстати) — то шаблон должен быть одним.
А вот как в него передаются данные — вопрос другой. Либо неявно через составитель — некоторым этот подход кажется нелогичным (не видно, что, откуда и когда передают в шаблон). Если так — можно передавать эти данные из родительского шаблона (т.е. того, где подключается @include(widgets.menu)), а он их передаёт во внутренний.
Вне зависимости от метода передачи для собственно генерации запроса я бы использовал метод класса модели, лучше — scopeXXX. Тогда не будет дублирования кода, запрос можно будет сделать в любом месте простым вызовом этого метода и сложность условий в нём не имеет значения — active = 1 или что-то сложнее.
Не в сети
Страницы 1
Универсальная вики-разметка
Работает на FluxBB (перевод Laravel.ru)