Symfony А где вы храните свои views?

[vld]

твит: https://twitter.com/sensiolabs/status/521938771739418625

А где вы храните свои views?
Почему в sensiolabs решили что так будет лучше?

 

[fixxxer]

Не знаю, почему они так решили.

Как по мне, какой подход выбрать, зависит от того, как построена работа с шаблонами.

Если делается приложение вида "сайт" с подходом "от дизайна", и с шаблонами работает верстальщик, которому вникать в структуру бандлов ни к чему - логичнее подход справа.
Если делается внутреннее приложение, либо какая-то система администрирования/управления чем-то, где дизайн строится из блоков а-ля бутстрап, и шаблоны пишет сам разработчик - логичнее подход слева.

 

[peon]

+ не нужно длинное логическое имя
+ все лежит в одной папке, а не раскидано по бандлам

использую два варианта одновременно, так как вьюхи вендорных бандлов лежат, как в первом способе
свое лежит так, как во втором способе

 

[Absinthe]

Внутри бандлов юзал.
Хотя мне гораздо больше нравятся новые Best Practices: огромный шаг в сторону удобства ларавел.

+ все лежит в одной папке, а не раскидано по бандлам

Я бы сказал, что все теперь свалено в кучу, а не аккуратно распределено, но смысл тот же
Если немного говнокода добавит много удобств, то такой говнокод полезен.

 

[vld]

Absinthe, > удобства ларавел
чем ларавел такой удобный? вчера с другом пытались написать на нем простенький api, плевались почти на каждом шагу

 

[Andkorol]

вчера с другом пытались написать на нем простенький api, плевались почти на каждом шагу

Больше конкретики – что именно не устраивает в laravel?

 

[Sender]

Скидывать все в кучу плохо, но и мельчить тоже нет смысла.
У нас был Payment внутри AppBundle, когда он распух, вынос его в отдельный PaymentBundle упростило его понимание.

Насчет app views, у нас сейчас в одном symfony проекте живет несколько app и каждый этот app имеет несколько дизайнов.
Все это активненько наследуется друг от друга с использованием twig namespaces, не исключаю чтобы все это пригладить надо будет научиться уезжать дизайнами в app views и для каждого дизайна уехать в отдельный app, но как там реализовать умное наследование когда шаблоны подцепляются сами - пока нету мыслей.

Но для простого проекта считаю незачем view хранить в app далеко от контроллеров. Тогда уж app делать полноценным местом хранения и php class'ов.

 

[vld]

> Но для простого проекта считаю незачем view хранить в app далеко от контроллеров. Тогда уж app делать полноценным местом хранения и php class'ов.

Sender, тогда это будет уже не symfony

 

[nonlux]

Я согласен с Best Practices, точнее я уже давно храню шаблоны + js + css (less) в отдельном проекте, который подтягивает composer.
Это удобнее в плане разделения по ролям:
- Для верстки шаблона абсолютно не нужно знать и использовать Symfony.
- Можно собирать легковесный прототип приложения и тупо тестировать верстку.
- Возможно использовать шаблон не только в Symfony

 

[Ярослав]

nonlux, верно, но ты хоть что-нибудь из этих удобств лично использовал?

 

[nonlux]

Ярослав, Да.

храню шаблоны + js + css (less) в отдельном проекте, который подтягивает composer.

Вообще на подобную организацию работы вывело несколько моментов:
- Atomic design (Понравился мне этот концепт)
- вопрос: "Как другому человеку дать работу по верстке при этом не заставляя его разворачивать проект"

В итоге я вышел на следующую организацию работы. Мой текущий проект, правда он не на Symfony, но это не суть.
Отдельный репозиторий для CMS и отдельный для верстки. Сейчас о нем.

Структура следующая:
- twig - шаблоны на твиг
- less - мои стили
- js - мои скрипты
- assets - доп ресурсы которые негде взять

Порядок работы:
- bower подтягивает необходимые зависимости
- Пишу какой-нибудь компонент страницы (кнопочку красивую, шапку, форму и т. д. ) - имеется ввиду и шаблон и стили
- Добавляю это хозяйство в style guide (сделано по примеру hologram)
Но style guide не генерируется, я все добавляю ручками, допустим так:

{%  set news_fake = { 'title': faker.realtext, 'text': faker.realtext } %}
{%  include 'organism/news-header.html.twig' with { 'news': news_fake }  only%}

faker - очень удобная библиотека для прототипа, сама вставляет левые тексты
- далее самопальной утилитой делаю рендер style guide и смотрю это все хозяйство в браузере.
- когда я сверстал целиком страницу, с помощь grunt, собираю все необходимые ресурсы ( объединяю, сжимаю, насилую)
- все собранные ресурсы + генерированные html страницы отправляются на сервер
- все страницы прогоняются через какой-нибудь сервис по кроссбраузерности (хз как по русски это обозвать)
- profit.

Ну а далее просто заставляем cms есть twig

 

[Absinthe]

- вопрос: "Как другому человеку дать работу по верстке при этом не заставляя его разворачивать проект"

Никак, иначе придется за него делать его работу.