Шаблоны: наследование или блоки?

[Духовность™]

причем тут я? где методы? нет никаких методов.

 

[С.]

Чем это лучше чем тупо прописать тоже самое в шаблоне-скелете конкретной страницы?

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

 

[Фанат]

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

Но в приведённом коде я вижу скорее неоптимальность реализации, чем подхода
почему не сократить дублирующиеся блоки до одного?

    {if $GlobalConfig.client}<link rel="stylesheet" href="/new_css/{if $GlobalConfig.client}.css" type="text/css">{/if}

    {if $GlobalDisplay.rel_image}    
    <link rel="image_src" href="{$rel_image.src}" />
    <meta property="og:image" content="{$rel_image.src}" />  
    <meta property="og:title" content="{$rel_image.content}" />
    <meta property="og:description" content="{$rel_image.description}" />   
    {/if}

В общих скелетах начинаются вот такие пляски:

Если это просто вставка, то её можно вынести в отдельный блок и просто инклюдить.

 

[Фанат]

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

 

[Absinthe]

Блоки однозначно.
Мейнстрим фреймворки на Python/Ruby (Django/RoR) используют блоки. Очень удобно.

 

[Духовность™]

почему не сократить дублирующиеся блоки до одного?

потому, что это никто не будет делать. я работаю в команде с проектом, который никто толком не знает из-за его объема. и никто не возьмет ответственность ради красоты делать такую группировку.

Если это просто вставка, то её можно вынести в отдельный блок и просто инклюдить.

можно и нужно. но на практике легче это всунуть непосредственно в общий шаблон.

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

1. дизайны сайтов меняются не часто
2. исправление одного разросшегося каркаса не легче чем создать новые 20 скелетов. тем более если меняется дизайн, то и верстка будет с нуля. не вижу в этом проблемы.

 

[AmdY]

Бред сивой кобылы, один гавнокод не оправдывает другого. Простой рефакторинг спас бы ситуацию, но вместо него вы принялись писать ифы.

{if $GlobalConfig.iphone}
меняем на массивы
{foreach from=$config.js item="css"}<link rel="stylesheet" href="{$css}" type="text/css">{/foreach}

в экшине или глобально для контроллера
$this->addCss('iphone');
для блока такой же форич и $this->addBlock('iphone');

 

[Духовность™]

ещё раз - это все накапливается как снежный ком никто не будет браться за рефакторинг десятка мегабайт кода

 

[Фанат]

Духовность™
Согласись, это не проблема метода.
В топике про правила игры я специально писал об этом - если проблема в неумелом использовании инструмента, то это не должно быть аргументом.

 

[ksnk]

Верстальщик не програмист - ему наследование не интересно.

После такого верстальщика придется подключать программиста для монтажа шаблона на этой "верстке". Что не сможет не сказаться на уровне зарплаты верстальщика...

Чтобы отследить что откуда отнаследовалось (пофайлово) должен бы существовать "режим отладки" когда в html-комментарии вписываются строки-файлы... Вроде, imho, достаточно очевидное решение. Такое есть? Кто про твиг что-нибудь знает?

 

[Фанат]

После такого верстальщика придется подключать программиста для монтажа шаблона на этой "верстке".

По факту, во всех известных мне компаниях так и происходит: шаблоны делает программист из хтмл-а, нарезанного верстальщиком.
В дальнейшем верстальщик может самостоятельно вносить правки в HTML шаблона, но вот первичная нарезка делается программистом.

Что не сможет не сказаться на уровне зарплаты верстальщика...

Да ладно уже гнать на верстальщиков. Не надо думать, что они хуже сервер-сайд программистов. У них просто другие задачи.
Это великие люди, решающие свои собственные задачи, никак с серверным программированием не связанные, и ничуть не менее сложные - требующие пространственного воображения, художественного вкуса и знания кучи специфических мелочей.
Нарезка хтмл-а в шаблон в эти задачи не входит.

Другое дело, что неважно для кого - верстальщика или бабы Мани-корректора - шаблон должен быть ЧИТАЕМЫМ. И в этом смысле наследование представляется не лучшим вариантом.

 

[fixxxer]

Фанат
А можешь пояснить, что именно нечитаемо в таком вот примере?

{% extends "base.html" %}

{% block title %}Index{% endblock %}
{% block head %}
    {{ parent() }}
    <style type="text/css">
        .important { color: #336699; }
    </style>
{% endblock %}
{% block content %}
    <h1>Index</h1>
    <p class="important">
        Welcome on my awesome homepage.
    </p>
{% endblock %}
{% block sidebar %}
    <h3>Table Of Contents</h3>
    ...
    {{ parent() }}
{% endblock %}

Мне это кажется читаемее инклюдов с ифами.

 

[Духовность™]

что parent() что инклюд - одно и тоже

 

[Фанат]

fixxxer
Ну, об инклюдах речь вообще не идёт.
А в остальном надо подумать.
На реальном примере будет выглядеть диковато, но альтернатива - духовное дублирование - ещё хуже...

 

[AmdY]

духовное дублирование

поцтолом.

fixxxer
как-то странно, что шаблон знает куда его вставляют. Мне удобнее наоборот.

 

[Фанат]

как-то странно, что шаблон знает куда его вставляют. Мне удобнее наоборот.

Но ведь альтернатива - куча ифов в основном шаблоне - тоже не фонтан.
Тем более, что по факту мы всё равно пишем шаблон не в стол, а в определённое место определённого шаблона - то есть, фактически он всё-таки знает, не?

 

[AmdY]

Фанат
скорее не ифы, а фореачи, в главном шаблоне пытаемся в цикле вывести всё что можно, а уже в контроллерах заполняем эти значения. В итоге шаблон справляется с 99% функционала без всяких костылей.