Aug 26

Вопрос, так, невзначай. Хотели бы вы аналог получить в Symfony аналог наследования шаблонов из Django?

PS. Палюсь… Ой как палюсь. :)

written by fxposter \\ tags: , ,


11 Responses to “Наследование шаблонов в Symfony”

  1. 1. npFly Says:

    Я вот всё непойму какой большой понт от этого наследования шаблонов? Может есть реальный пример где наследование шаблонов необходимо или как минимум результат рефакторинга дисплэй логики.
    В Symfony я думаю заимплиментить эту фичу не составит труда, всего навсего надо расширить возможности PHPView.

  2. 2. FX Poster Says:

    Пример привожу из практики:
    Есть у меня товар, который должен отображаться немного по-разному в двух разных случаях – когда в него заходят из категории, например, и из архива. При заходе из архива не должны показываться цена и еще несколько ссылок/блоков. В остальном – страницы прямо 1 в 1. В случае с обычным путем вывода в Symfony мне прийдется или делать два ОЧЕНЬ похожих, но всё-же отличающихся файла, или делать один файл, но с довольно большой условной логикой, что лично мне очень не нравиться (как, в принципе, и первый вариант). С наследованием такая штука реализуется намного проще и приятнее.

  3. 3. muxx Says:

    Да, все правильно Паша говорит, в тех же магазинах наследование пригодилось бы в списковых страницах — страница категории, страница поиска, страница новинок и т.п. Примеры можно найти много, вещь однозначно полезная!

  4. 4. npFly Says:

    FX Poster
    Эту проблему можно очень просто решить и без наследования. К примеру как на Youtube. Там для отоброжения Grid и List меняетса всего лишь правило CSS. Скорее то что ты назвал проблемой это недочёт вёрстки. Другой вариант это конечно же два фрагмента шаблона, но тут как ни крути с наследованием шаблонов кароче не выйдет. В любом случае будет один параметр и два шаблона.
    Если уж так хочетса то можно использовать сам Smarty вместо слоя представления в symfony. Но по мне вариант который предлагает symfony, а именно strict php самый лучший в отличие от дополнительного парсера.
    Наследование шаблонов так же можно применить посредством XSLT, который в свою очередь так же можно выбрать как слой представления в symfony.

  5. 5. FX Poster Says:

    Нет, ты меня не понял. Я не хочу что-то представить в другом виде, хотя и этот вариант тоже подходит под наследование. Я хочу показать ту же страницу, с немного другими данными, кое-где измененными элементами и т.д.

    Вот ты используешь layout’ы в Symfony. А почему ты просто не меняешь страницы с помощью CSS? Именно так выглядит твой вопрос. Связка layout < -> template – это просто один из способов реализации наследования шаблонов, в котором ты переопределяешь внутренний контент. А теперь подумай шире – почему ты должен постоянно переопределять ВСЁ, что вставляется в layout? Почему ты не можешь отнаследоваться от другой страницы и использовать как layout уже её? Т.е. вместо одного уровня наследования (который в Symfony УЖЕ есть, и он работает, и ты им пользуешься!) мы получаем много уровней, и вместо того, чтобы переопределять ВЕСЬ контент страницы каждый, мы переопределяем лишь его часть, наследуя уже переопределенную часть от другого темплейта.

    Может сумбурно получилось, если непонятно – спрашивай.

    А вот конец твоего комментария мне непонятен. Зачем еще один слой? Всё это делается исключительно на, как ты выразился, strict php, в использовании вьюх ничего не меняется, лишь ДОБАВЛЯЕТСЯ новая опция – возможность наследоваться не от layout’а, а от другого уже созданного темплейта.

  6. 6. npFly Says:

    Я ни в коем случае не имел ввиду смену контента страница при помощи CSS. Я говорил о возможности отображать елементы страницы по разному и даже с разным набором данных. Для этого действительно вполне может сойти манипулция CSS правилами.

    N-количество уровней можно достигнуть используя фрагменты шаблонов(partials) и по поводу “довольно большой условной логики” это ты явно преувеличил, так как в обоих случеях условная логика понадобится и будет примерно одинакова.

    Я не говорил об ещё одном слое, я говорил о замене либо модификаций уже сужествующего слоя представления, хотя как пример для реализаций наследования шаблонов в стиле Smarty действительно потребуется парсер, поэтому было бы неплохо если бы ты ещё и показал то как ты видишь реализацию этой фичи в symfony.

    Может быть я конечно чего то не доконца понимаю, всё таки до сих пор не услышал весомого аргумента в пользу наследования шаблонов. Если бы ты дал реальную задау я бы мог решить её средствами symfony и на её примере можно было бы подумать о преимуществах и недостатках, а так всё равно что альцем по воде водить :)

  7. 7. Vyacheslav Says:

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

  8. 8. FX Poster Says:

    npFly
    Давай ты подумаешь сначала над тем, почему ты сейчас используешь наследование шаблонов, используя layout? И о том, почему ты не инклудишь партиалы во всех страницах (header и footer), вместо “непонятно зачем нужного layout’а, который проповедует наследование шаблонов”. :)

    Vyacheslav
    Недостатки:
    1. Много переменных передается в шаблон лишь для того, чтобы указать, какие partial’ы поставить.
    2. Появляется куча ненужных партиалов, которые и поюзать больше негде. :)

    All
    Мыслите шире! :)

  9. 9. Romiz Says:

    Я не понимаю в чем сыр бор?
    Если наследование шаблонов где-то реализовано, то кто-то посчитал это удобным и с удовольствием пользуется, найдется ещё куча людей которые полюбят этот подход.
    Говорилось про XSLT. Насколько я понял суть этой технологии шаблонизации, перед выполнением преобразования сначала необходимо собрать-сгенерить XML из тех же “кусочков-партиалов” :)
    Я не прав?

  10. 10. FX Poster Says:

    Вы о чем, собственно?

  11. 11. npFly Says:

    Romiz
    Необезательно, ты совершенно так же будешь передовать переменные в шаблон, а XSLT будет генерировать XHTML.

Leave a Reply