Пользователь
0,0
рейтинг
22 ноября 2009 в 17:35

Разработка → Перевод: Шаблонизаторы в PHP — подведение итогов перевод

PHP*
Перевод итога обсуждений поста в блоге Фабиена (Fabien Potencier) на тему PHP шаблонизаторов и Twig.

-----------------------------------------------------------------------
Мой пост о шаблонизаторах в PHP (прим. перевод ) получил более 70 комментариев на данный момент. Можно отметить, что многие из них хорошо продуманы и аргументированы. Спасибо всем кто потратил свое время на принятии участия в конструктивной дискуссии. Я действительно горд тем, что PHP сообщество (по крайней мере, та его часть которая читает мой блог) способна дискутировать на эту рискованную тему, не приступая к флейму (flame war)! Я так же впечатлен количеством людей желающих продвинуть свои собственные шаблонизаторы ;)

Перед тем как начать отвечать на некоторые вопросы, я хотел бы напомнить о том что мне нравятся шаблоны на чистом PHP. И нужно помнить что в symfony используются шаблоны на чистом PHP с самого начала. Как факт, я выступал в защиту использования для шаблонов чистого PHP со своего первого проекта на PHP и никогда не использовал ни одного стороннего шаблонизатора. Итак, я не против PHP для шаблонов; я просто понял что ограничения PHP, как шаблонизатора, стали все больше и больше меня раздражать.

Как указал Eli, «Я [Fabien] представляю шаблоны на PHP в таком виде потому что хочу продвинуть шаблонизатор который я создал»

Мне также понравился комментарий от Tchalvak: «Вопрос о том что лучше PHP или шаблонизатор не самый главный, гораздо важнее (и на что проще ответить) это использовать шаблоны или нет. Шаблоны — и выделение представления — необходимы. А в каком виде оно представлено, не так уж важно. » Он отлично подвел итог вопросу обсуждения.

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

Twig. Причина.


Я начал искать шаблонизатор несколько месяцев назад. Люди, знающие меня, знают что я не люблю изобретать колесо. Поэтому я не хотел создавать свою новую библиотеку с нуля.

Я искал хорошие шаблонизаторы, пробовал некоторые из них, и в итоге нашел Twig. И как только я начал его использовать, я понял что это тот бриллиант который я искал (за его функциональность и простую, красивую архитектуру). И, т. к. Twig не был самостоятельным проектом, я начал переписывать его. После некоторых улучшений, таких как режим «песочницы», я решил связаться с Армином (Armin) и поговорить о будущем Twig.

Т.е. ты не продался… все еще?


Даже если вы не верите в мои аргументы, это нормально. Я не хочу делать из Twig универсальный шаблонизатор для PHP. Я действительно думаю что Twig не один на рынке шаблонизаторов, но я первый кто решил что он не будет использоваться во всех новых проектах на PHP!

Если вы ищете шаблонизатор на читом PHP и имеющий встроенную возможность наследования шаблонов, блоками, вспомогательными функциями (хелперами) и прочим, хорошие новости в том что несколько недель назад я представил компонент шаблонов Symfony. Это абсолютно самостоятельный (standalone) компонент который не зависит ни от чего, и я уверен что многие, кто хочет использовать PHP у себя в шаблонах, полюбят этот проект.

И даже лучше — вы можете использовать Twig и компонент Symfony Templating для получения наилучших результатов. Используйте компонент для всех ваших шаблонов, и Twig если вам необходим режим «песочницы».

О синтаксисе


Множество комментариев на тему синтаксиса, и проблем синтаксиса PHP, которую я поднял. Речь не красоте синтаксиса, и, если вы считаете что мои аргументы являются обсуждением «цвета велосипедных навесов» (прим. русская версия), подумайте еще раз.

Ключевым моментом моих аргументов является то что шаблонзаторы должны стремиться к золотой середине (?? sweet spot). Шаблонизаторы должны найти компромисс в наличии возможностей — достаточно, но не слишком много. Как я и говорил в предыдущем посте, язык шаблонизатора относится к логике представления. И, конечно, простые условия и циклы это часть логики представления. Но желаете ли вы использовать функцию array_chunk() в шаблонах? Скорее нет. Это должно быть реализовано в контроллере или модели, зависит от того что вы хотите сделать.

Также в шаблонах много HTML кода с небольшим содержанием PHP. И этот кусок кода для меня полностью неприемлем:
<?php
    if ($items) {
        foreach ($items as $item) {
            echo "* {$item}\n";
        }
    } else {
        echo "No item has been found.\n";
    }
?>


Многим, кажется, нравятся короткие теги PHP. Первое — математика. Если вы сравните запись <?= $var ?> с записью <?php echo $var ?>, то увидите разницу в 7 символов, а не 2. Но это не главная проблема.

Кроме проблем с поддержкой XML и тем что параметр конфигурации short_open_tag различается у хостинг-провайдеров, это также вопрос стандартизации кода:
  • PEAR: «Всегда используйте <?php ?> для отделения PHP кода, не краткий вариант <? ?>. Это обязательно по соглашению PEAR и также является наиболее гибким путем использования PHP кода на разных операционных системах и различных конфигурациях»
    «Always use <?php ?> to delimit PHP code, not the <? ?> shorthand. This is required for PEAR compliance and is also the most portable way to include PHP code on differing operating systems and setups.»
  • Zend: «Короткие теги не разрешены ни в коем случае.»
    «Short tags are never allowed.»


Pear и Zend достаточно серьезные проекты, поэтому у них были причины запретить короткие теги, не так ли?

Но как Eli упоминал в своем посте, я бы тоже был рад знать что в PHP занялись этой проблемой: "… есть ряд людей (включая меня [Eli]), которые думают о предложении новой возможности директивы short_tags в PHP, дающей возможность не только включать и выключать ее. Но и добавляющей 3й вариант — который разрешит <?= ?>, запрещая <? ?>"

О верстальщиках


(прим. оригинальное web-designers здесь и далее будет переведено как верстальщик)

Споры не о том должны ли верстальщики понимать PHP или нет. И, несомненно, не о том что верстальщики не достаточно умны. Конечно, они могу могут узнать немного PHP… до тех пор пока не узнают слишком много и не начнут писать код не относящийся к их шаблонам (например выбирать записи напрямую из БД). Ну конечно, они бы не допускали такой ошибки если бы знали о паттерне MVC. Но стоп, они уже не верстальщики — они программисты.

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

Экранирование


Некоторые комментарии выступают в защиту того что экранирование должно быть выполнено в контроллерах. Это не будет работать. Как писал John Campbell: «Проблема в том, что контроллеры не знают что будет выведено, и им также неизвестно как именно нужно экранировать»

Проблема сама по себе непростая. С одной стороны программисты должны заниматься экранированием, но не могут делать этого в контроллерах. С другой — верстальщиков не должно заботить экранирование, но только в шаблонах его можно выполнить имея достаточно информации. Поэтому автоматическое экранирование для меня является лучшим компромиссом, плюс то что приложение по-умолчанию «практически» безопасно тоже является преимуществом.

Говоря о автоматическом экранировании, можно сказать, что я знаю об этом достаточно, потому что в symfony это возможность существует с 2006 года. Могу вам рассказать, что издержки скорости работы такой функциональности очень большие. В Twig это все компилируется, и поэтому издержки отсутствуют.

О «песочнице»


Режим «песочницы» не ориентирован на верстальщиков. В основном, это относится к ситуациям когда люди «извне» могут изменить шаблоны (подумайте о вебмастерах которые настраивают шаблоны своей CMS или платформы блогов из системы управления).

Развитие безопасности Dwoo и Smarty это правильный шаг в этом направлении, но не такой мощный как полный режим «песочницы». Насколько я понимаю, все это в основном о разрешении PHP кода в шаблонах или нет, а также об ограничении доступных PHP-функций (поправьте меня если я ошибаюсь).

Режим песочницы контролирует все — от допустимых тегов, до разрешенных методов объектов (документация Twig объясняет концепцию и то, как она работает)

О скорости


Большинство шаблонизаторов компилируют шаблоны в PHP код. Поэтому скорость лексинга (lexing), парсинга (parsing) и компиляции не играет большой роли, какую играет скорость выполнения. Ниже скомпилированная версия шаблона Hello {{ name }}:
/* Hello {{ name }} */
class __TwigTemplate_1121b6f109fe93ebe8c6e22e3712bceb extends Twig_Template
{
  public function display($context)
  {
    $this->env->initRuntime();
 
    // line 1
    echo "Hello ";
    echo (isset($context['name']) ? $context['name'] : null);
  }
}


Многие беспокоятся о отладке. Как вы можете видеть, сгенерированный код очень чист, содержит название и строки оригинального шаблона. Этого должно быть более чем достаточно, чтобы с легкостью отладить все проблемы.


Вы можете посчитать это невероятно многословным (verbose) чем PHP версия, и, конечно, версия на PHP будет невероятно проще:
Hello <?php echo $name ?>


Но обратите внимание на сгенерированный код большинства шаблонизаторов и вы сами увидите что Twig генерирует наиболее чистую и короткую версию.

По просьбам многих, я переписал тесты, совместив фазу компиляции и рендеринга. Как я и ожидал, это не сильно изменило цифры. Компиляция таких простых шаблонов не имеет важного значения к времени их рендеринга 10 000 раз.

Я также протестировал шаблоны на чистом PHP. Ниже обновленная таблица:

Библиотека Время (сек) Память (Кб)
Чистый PHP 2.4 114
Twig 3 383
PHPTAL 3.8 598
Dwoo 6.9 1 645
Smarty 2 12.9 610*
Smarty 3 14.9 799*
Calypso 34.3 614
eZ Templates 53 2 783

Обратите внимание что количество памяти, использованное Smarty, гораздо меньше чем в моем предыдущем тесте, потому что я обернул весь цикл в ob_start()/ob_end_clean() что было нечестным по отношению к другим шаблонизаторам. Сейчас это было исправлено.


Как и ожидалось, PHP быстрее чем Twig для простых шаблонов. Но чем они будут сложнее, тем меньше будет разница, благодаря чистоте кода который генерирует Twig.

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


Тесты вы можете скачать здесь: fabien.potencier.org/benchmarks.tgz

Twig и Symfony


Этот раздел для тех, кого интересует внедрение Twig в Symfony.

Symfony 1.3/1.4


Очевидно, что Twig не будет частью symfony 1.3 т. к. в конце следующей недели подходит срок заморозки развития функциональности (feature-freeze deadline), а так же потому что symfony 1.3 это эволюция symfony 1.2, а не революция.

Если кто-то желает сделать Twig плагином к symfony 1.3, начните дискуссию в списке рассылок разработчиков symfony, и я помогу вам приступить к работе.


Symfony 2.0


На данный момент ничего конкретного по поводу Symfony 2 еще не решено, но Twig не будет шаблонизатором по умолчанию. Я думаю Twig будет доступен в качестве опционального плагина, хорошо интегрированного с ядром. Например, он может быть использован для генерации бэкенда (admin-generator) — для упрощения его настройки (кастомизации).

И, спасибо компоненту Symfony Templating, разработчики смогут использовать Twig и чистый PHP вместе, в зависимости от необходимостей.

Итак, если вы не хотите связываться с шаблонизаторами — используйте чистый PHP; но если вы захотите выиграйть используя Twig вы можете использовать и его (он будет встроен). И, конечно, если у вас есть другие плагины они не станут проблемой.

Итог


Надеюсь что этот пост ответил на некоторые вопросы поднятые в комментариях.
Перевод: Fabien Potencier
Евгений @zhekanax
карма
58,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (68)

  • +1
    «Я не хочу сделать из Twig универсальный шаблонизатор для PHP, далеко от этого.» — где логика, причем там ", далеко от этого"? Переводил через Гугл транслейт?

    Поработай на орфографией:
    … согласен с большинствоим из них. Сейчас…
    … несколько месяцв назад…
    … хорошие нвоости в том что…
    … представил компонет шаблонов…
    … если вы считате что мои аргументы…
    … найти компромис в наличии… компромисс с 2 «С»
    … говорил в предыдщем посте, язык…

    и так далее… очень много ошибок!
    • +3
      Гугл транслейт не вставил бы опечаток :)
      Перед публикованием полтора раза перечитал текст, видать уже глаз замылился.
      • 0
        >в комментариях, и, по-просту, согласен с большинством

        >шаблонизатор на читом PHP и имеющий

        > (прим. русская версия), подумате еще раз.

        >относится к логике предствления. И, конечно, простые условия и циклы это часть логики предствления.

        > И этот кусок кода для меня полносью непреемлем:

        >это также вопрос стандратизации кода:

        > для меня является лучшим копромиссом, плюс то что

        Хинт: Встроенный спелл-чекер файерфокса все эти ошибки подсветил и почти везде предложил корректные варианты исправления. Еще много похожих ошибок, но пока некогда
        • 0
          У спеллчекера галочка почему-то стояла на английский язык. Исправил :)
    • +1
      Да, по поводу стилистики текста, корректности перевода и общей читаемости — это мой второй перевод и может хоть здесь скажут что то, что я написал читать невозможно и пора бы перестать этим заниматься? :)
      • +1
        Делай перевод своими словами, что бы он был максимально простым и понятным, а также добавляй картинок, ибо текст «в сухомятку» не очень идёт
      • 0
        Читать возможно, хотя многие ошибки (орфография и пунктуация) бросаются в глаза. В оформлении мешают читать примечания переводчика и куски оригинального текста без выделения, обычно их как-то оформляют, чтоб в глаза не бросались, курсивом, например. Но это придирки уже наверное, опечатки (надеюсь ;) ) и запятые — больше всего мешают. Причём большинство опечаток выявляются практически любым спелл-чекером. С запятыми сложнее — знаю только одну программу, которая хоть как-то пытается обнаружить и исправить ошибки пунктуации, но рекомендовать ее не могу, ибо закрытая, платная (хотя сейчас бета версия ее очередного релиза доступна бесплатно )и только под одну (или две, под Маком не работал в ней) платформу.

        P.S. И, по-моему, не стоит в публикациях употреблять сокращения «т. к.», «т. е.» и т. д., и т. п. :) Ведь не конспект для себя, и не холивар в комментах ;)
  • НЛО прилетело и опубликовало эту надпись здесь
  • –1
    Песочница — абсолютно бесполезный режим. Если вы вдруг решили сделать огромного блогомонстра с возможностью своих шаблонов, по такому случаю можно и свое что-нибудь, причем желательно синтаксис брать с какой-нибудь существующей блогосистемы.
    • +1
      А если цмс, и клиент хочет править шаблоны, но нет желания постоянно выяснять что он там сломал?
      • 0
        Удар ниже пояса ;)
      • 0
        1) Клиент неадекват, с ним все равно ничего хорошего не выйдет
        2) А при чем тут sandbox? Sandbox предполагает защиту от выполнения подсунутого злоюзерами кода, а клиент вряд ли будет пытаться взломать собственный сайт :)
        • +1
          1) клиент предпочитает заплатить один раз, а не вызывать разработчика по каждому чиху — это неадекват?
          2) необязательно попытка взлома нужна, чтоб обрушить систему — «не ищите злого умысла, там где действия можно объяснить простой глупостью» (почти с) не помню кто
          • 0
            Дык сендбокс никак не защищает от неправильного шаблона и ошибки сам не исправляет. А насчет сломать — ну как он это сделает, клиент случайно напишет в шаблоне exec('rm -rf') или sql_query(DROP table)?

            Я еще раз говорю, он тут бесполезен.
        • +1
          Хинт: клиент не обязательно работает с сайтом/админкой лично. Я бы даже сказал, «как правило». Продолжать?
          • +2
            Согласен, как правило так и случается.
            Хорошо, еще один пример из жизни: клиент хочет предоставить владельцам платных акканутов возможность редактировать шаблоны их персональных страниц (назовем это так). Т. е. шаблоны должны редактировать непосредственно пользователи сайта. Выходов может быть несколько — писать свой язык шаблонов под эти узкие нужды или использовать некий, жутко урезаный, режим песочницы.
            • +1
              Да вагон таких примеров. Начать хотя бы с примитивного — нужно править шаблоны писем к юзеру.
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Может быть потому, что xslt в приведенном списке шаблонизаторов не совсем уместен?.. =)
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Ну как минимум в том смысле, что для xsl шаблон требует на вход готовый xml документ, когда перечисленные шаблонизаторы принимают от скрипта только переменные значения (не знаю как все, но smarty — точно).
          • НЛО прилетело и опубликовало эту надпись здесь
            • 0
              Не доводилось как то. Везде, где разумнее использовать XSLT — использую, а для других случаев меня вполне устраивает смарти. Однако после прочтения этой статьи задумался над тем, чтобы попробовать Twig.
              • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        >xslt в приведенном списке шаблонизаторов не совсем уместен?..
        В прринципе да. Стандарт, поддерживаемый во всех современнвх платформах, включая PHP и разнообразные самопальные библиотеки, которым нет числа, и которые порождают холивары уже много лет, никак не укладываются в один ряд.
        • 0
          Согласитесь, что пресловутый порог вхождения в XSLT довольно высокий, а в PHP традиционно низкий, как и у большинства (со всеми не знаком, может и у всех) шаблонизаторов из списка? И это не учитывая совершенно разные парадигмы языков.

          Если XML+XSLT жестко прикрутить к PHP, как единственный способ вывода HTML и пр., то, сдаётся мне, популярность PHP среди начинающих веб-разработчиков резко пойдёт на убыль, но вот росту популярности XSLT это вряд ли поспособствует.
          • 0
            Имхо очень большое имхо, если не глубоко не копать и применять предельно тупой XSLT-стиль (3-4 основных инструкции) он не сложнее Smarty. И уж точно проще PHP.
            • 0
              Вот тут тред почитайте, второй раз историю лениво пересказывать, сорри :)
          • 0
            Кстати если сравнивать по сложности стандарты+баги+фичи CSS, JS и XSLT, последний выглядит достаточно прозрачным и простым. Я плохо понимаю почему верстальщику, который смог выучить 10-15 багов ie6 + Opera + FF сложно выучить азы XSLT.
    • 0
      Наверное потому, что XSLT не является шаблонизатором в том смысле, который автор поста вкладывает в это слово, или просто не отвечает его критериям:
      — краткость — по-моему к достоинствам XSLT это сложно отнести ;) не говоря уж о том, что данные для XSLT надо готовить специально. Причем удобным способом мне представляется для этого использование шаблонизаторов :), так как по сути их назначение — легко перевести структуры данных PHP в текстовые форматы, такие как HTML и XML
      — синтаксис, ориентированный на шаблоны — тут, мне кажется, XML (любой) плохо подходит, ведь любая реализация языка шаблонов будет накладываться поверх синтаксиса собственно XML.
      — повторное использование (прежде всего в смысле объектно-ориентированного наследования) — повторное использование есть, но мне оно показалось жутко неудобным
      — режим «песочницы» — честно говоря, так и не понял толком что это и можно ли, — и нужно ли, — реализовывать это на XSLT.

      Внутреннее представление данных в XML и преобразование их во внешнее с помощью XSLT — мощная и универсальная технология, но вряд ли имеет смысл использовать её для простых задач, типа выдачи данных из нескольких SQL запросов в двух-трех однотипных представлениях. Не говоря уж о том, что порог вхождения для верстальщика (да и программиста, привыкшего к императивным языкам) очень высок.
    • 0
      Применять xslt, на мой взгляд, уместно если в таком случае: дали верстальщику на верстку, но с выбором серверного языка программирования не определились.
      • НЛО прилетело и опубликовало эту надпись здесь
  • НЛО прилетело и опубликовало эту надпись здесь
  • –2
    > Pear и Zend достаточно серьезные проекты, поэтому у них были причины запретить короткие теги, не так ли?
    Возможно. А возможно и не было. Причины против названы смешные: невозможно работать с XML через задницу(лапшой из XML+PHP) и недостаточная портируемость(если кто-то специально отключит его и запретит .htaccess(для апача)).
    Обе причины явно надуманы.

    Что касается экранирования, то на практике ситуаций. где экранировать не надо — немногим меньше тех, где надо. Поэтому верстальщик шаблонов САМ должен расставлять нужное.
    • +1
      >с XML через задницу(лапшой из XML+PHP)
      По-моему использование PHP как шаблонизатора для генерации xHTML страниц (и любых других XML представлений), как раз и представляет собой «лапшу» из XML+PHP. Или XML код надо генерировать через echo "<a href="#">".$var."</a>?

      >если кто-то специально отключит его
      В php.ini short_open_tag отключены (давно?) при установке, надо его править ручками, чтобы включить.
      • +1
        >По-моему использование PHP как шаблонизатора для генерации xHTML страниц
        Это исключение, которое обходится элементарным хаком из нескольки символов, которые мы все знаем, и на проект нужно лишь пару раз.
        Если откажетесь от хака в несколько символов в 1 месте — аналогичное кол-во символов придется писать при каждой переменной в шаблоне. Что не выгодно.

        > В php.ini short_open_tag отключены (давно?) при установке, надо его править ручками, чтобы включить.
        При установке все зависит от дистрибуции ;) У меня по умолчанию работает.
        • +1
          >Это исключение, которое обходится элементарным хаком из нескольки символов, которые мы все знаем
          Это мы знаем, но а верстальщик может и не знать. Как минимум, это исключение нужно будет документировать, а кто-нибудь, как всегда бывает, не заметит строчку в документации :( Ну или при личном обучении я могу забыть это сказать верстальщику.

          >При установке все зависит от дистрибуции ;) У меня по умолчанию работает.
          Не спорю, но 3 используемых мною способа (вининсталлер и сборка из сорцов с php.net, установка из репа убунту) дают один результат
          • 0
            Верстальщик должен знать свой инструмент.
            PHP на уровне инструмента для верстки учится за час. В том числе и с этим хаком, про который не надо забыть рассказать. Тем более что вертальщику надо отдать шаблоны, сделанные программистом(ага, черные буквы на белом фоне), которые он и будет изучать, чтобы понять, что надо выводить.

            По поводу настройки php.ini — на все воля админа. А как админу что настраивать говорит программист(флаги и параметры пхп, нужные модули и т.д.)
            • 0
              А я бы не рискнул доверить PHP верстальщику…
              Как перешел на XSLT, понял, что с другими шаблонизаторами работать больше не могу. Если программизм серьезный, то идеальный вариант такой: программисты выдают XML где все данные подготовлены и представлены в нужном виде, и им абсолютно все равно, что с этими данными будут делать верстальщики.

              Моя практика показывает, что верстальщику намного проще освоить xsl, чем php. Не целиком, а на уровне <xsl:template/> и <xsl:apply-templates/>
              • 0
                >Если программизм серьезный, то идеальный вариант такой
                У идеала всё хорошо, кроме того, что в реальной жизни не встречается, увы.

                >Не целиком, а на уровне <xsl:template/> и <xsl:apply-templates/>
                Может отсюда растут ноги у легенд (судя по комментам) о громоздкости и медлительности XSLT-кода? Когда, только познакомившись с XSLT, я горел энтузиазмом и сделал пару рабочих сайтов «на уровне», то был неприятно удивлён этой самой громоздкостью и медлительностью (про скорость разработки скромно промолчу :) ). Потом, через довольно большое время, познакомился с человеком, занимавшимся XSLT серьезно несколько лет, поспорили с ним, в общем за ночь (причем не в очень трезвом состоянии :) ) он выдал XSLT файлы раза в 3 меньше по размеру чем мои и раз в 5 быстрее. Да еще ругался на мой XML, говорил, что при грамотном XML еще процентов 20 можно было бы «вытащить». То есть по сути XML+XSLT примерно оказались равны по скорости Smarty, чуть больше по размеру, намного элегантнее (имхо), но… мои Smarty шаблоны были написаны примерно за то же время, что и XSLT, хотя изучал я его несколько часов, а не несколько лет.

                P.S. После того случая перешёл на native PHP шаблоны :)
                • +1
                  > У идеала всё хорошо, кроме того, что в реальной жизни не встречается, увы.
                  Мне кажется, именно так сделали в яндексе. Не думаю, что XSLT там используется только из-за разных форм вывода одной информации (хотя и это тоже). Есть еще много крупных проектов, разные части которых написаны на разных языках. Сам на одном из таких работал. Если верстка и программинг разделены, то это вообще никого не парит.

                  Про ваш случай… Да, тут тонкий момент. Чтобы писать на смарти, достаточно его поизучать пару часов. Чтобы писать на XSLT хорошо, его надо полюбить) А плохо на XSLT лучше вообще не писать. Это будет медленно, некрасиво и только пополнит ряды ненавистников этой технологии. Впрочем, это относится не только к XSLT…
                  • +2
                    Для крупных проектов, с кучей разных платформ, унаследованных сервисов (которые уже никто не помнит как работают :) ), плановое переписывание критических участков на других языках и т. д., XML+XSLT, наверное, оптимальный вариант. Но вот для задач типа визитки, хомяка, блога, форума, галереи и т. п., с кодами которых работают максимум 2-3 человека, XSLT подойдёт только если уметь на нем писать хорошо, что значит его любить ;) Причём любовь бывает разная, я вот его люблю, как люблю какую-нить актрису — приятно иногда посмотреть ;) PHP шаблоны (да и вообще язык) тоже люблю, как любят некрасивую, сварливую и вроде даже надоевшую, но свою жену :) Сейчас вот еще пытаюсь любовницу завести (Python и Django) :D
              • +1
                Мой верстальщик освоил шаблоны на пхп с первого раза. Это заняло минут 15 объяснений со всеми тонкостями. Правда она умеет программировать на C++)
                • 0
                  Что и требовалось доказать — императивный подход куда проще для освоения :)
                  • 0
                    Между понятиями «проще в освоении» и «мощнее и проще в использовании» я выберу однозначно второе.
                    • –1
                      Рассмотрим предельные случаи? :) И, опять-таки, в чём мощь? Насколько я знаю основные доводы в пользу XSLT:
                      — кросс… (платформенный, языковой, еще черти-какой :) ) стандарт
                      — как следствие, поддержка основными продуктами от клиентских приложений до серверных СУБД
                      — «идеологические» вещи, такие как полное отделение кода от данных, а данных от представления, и что немаловажно без костылей типа {% foreach… %} (хотя похожие костыли вроде есть и в XTML, по крайней мере для PHP).
                      — как следствие, более четкое разделение обязанностей в команде и облегчение развития и поддержки
                      — даже какая-то красота и элегантность решения (в принципе, самой идеи, конкретную реализацию в виду не имею :) )
                      — возможно даже большая скорость разработки (при должном уровне знаний и опыта, потому «возможно», утверждать не имею права, скорее обратное :) ) и с нуля, и правки, включая полную переделку (а фреймворки XSLT есть? по типу CSS)

                      Но вот «мощь» как таковая, чтоб парой строк решить задачу для которой в других шаблонах понадобится десятки строк кода, особенно в решениях, которые заведомо не будут ни расширяться, ни мигрировать на другую платформу, ни изменять формат данных… в общем решающих конкретную задачу по преобразованию PHP-данных в HTML-код «здесь и сейчас» — не вижу я её, а ведь это, пожалуй, самая распространенная задача в веб-программировании (по числу «инсталяций» :) )
                      • 0
                        И что, что стандарт? Аналоги шаблонов типа PHP есть в любом ЯП и разница лишь в синтаксисе, котоорый элементарен.
                        Минус в наглядности. Набор правил как правило не нагляден.

                        > без костылей типа {% foreach… %}
                        Это не костыль, а логика отображения. Не стоит называть альтернативную вещь костылем, если она не хуже.
                        Я ничего не имею против XSLT, но кроме плюсов у него есть и минусы. Иначе бы его все юзали ;)

                        • 0
                          Что-то я не понял, о чем мы спорим :) Видимо фразу «Между понятиями «проще в освоении» и «мощнее и проще в использовании» я выберу однозначно второе», я понял неправильно, как однозначный довод в пользу XSLT. Отсюда и «костыль» — обычный довод и «трупехепешников», не терпящих никаких шаблонизаторов, кроме «великого и могучего», и любителей другого «великого и могучего» :)
                      • 0
                        Всё не так))
                        Во-первых, в XSLT есть вполне себе for-each, и есть много народу, которые пытаются на нём (на XSLT) программировать. Думаю, это не основное применение языка)
                        По поводу универсальности тоже можно поспорить. Когда объем данных большой, XSLT становится ощутимым тормозом. Например, подробный годовой отчет с кучей параметров с детализацией по дням.

                        XSLT настолько прост и изящен, что многие мои знакомые программисты, увидев его, стали его использовать его во всех проектах, даже в хомяках.

                        Попытайтесь встать на точку зрения не-программиста (верстальщика) и сравните 2 конструкции:
                        <?
                        foreach ($items as $item) {
                        echo "* {$item}\n";
                        }
                        ?>

                        и

                        <xsl:template match='item'>
                        … красивый html-like код без страшных конструкций
                        </xsl:template>

                        <xsl:apply-templates select='item'/>
                        • 0
                          Вот я тоже считал его простым и изящным, пока не попытался натянуть на существующий сайт :( Вся красота и изящество куда-то резко пропали, когда пришлось пришлось писать километровые XPath (часто, кстати, забывают, что еще и XPath нужно знать, а не только собственно XSLT) в десятиэтажной вложенности шаблонах, чтобы выцепить именно нужный item из десятка других.

                          P.S. Смотреть страшно на PHP код, специально для контраста? ;) Такой как-то красивее (правда ради красоты пришлось принципами пожертвовать, которые в соседнем треде утверждал :) ):

                          <? foreach $item in $items: ?>
                              * <?=$item;?>
                          <? endforeach; ?>
                          


                          P.P.S. Что-то я совсем XSLT забыл, не могу понять а где в коде без страшных конструкций собственно значение item выводится?
                          • 0
                            Питон съел мой мозг, доучился называется :) Конечно foreach($items as $item)
                  • 0
                    Вредные привычки завсегда усваиваются проще чем полезные :)
                    • 0
                      Может тогда в топик «Шаблонизаторы в Лиспе» пойдем? PHP вообще вредная привычка ;)
                      • 0
                        Можно, если там есть XSLT :)
  • –5
    Извините, но это явно перебор: Зачеммне сколько сущностей для выполнения задач шаблонизатора?
    Это какой-то извращенный подход к архитектуре.

    Twig_Autoloader
    Twig_Loader_Filesystem
    Twig_Loader_String
    Twig_Loader_Array
    Twig_Environment
    И еще черт знает сколько непоятно зачем созданных класов.

    И вот это все для инициализации:

    require_once '/path/to/lib/Twig/Autoloader.php';
    Twig_Autoloader::register();
    $loader = new Twig_Loader_Filesystem('/path/to/templates');
    $twig = new Twig_Environment($loader, array(
    'cache' => '/path/to/compilation_cache',
    ));


    Мой идеальный шаблонизатор должен предоставлять весь функционал статическими методами одного класса и не плодить лишней херни.


    Ну вот как-то так:
    Tpl::$conf=array(
    'cache'=>true,
    'cache_dir'=>'/cache/tpl/',
    'tpl_dir'=>'/templates/'.$theme,
    'comment_open_tag'=>'{*',
    'comment_close_tag'=>'*}',
    /*и так далее, но в общем шаблонизатор должен работать и без каких-либо доп. опций*/
    );

    Tpl::assign($var);
    return Tpl::fetch('news/news.htm');


    Формат шаблонов должен быть .htm, потому что в первую очередь верстальщику нужна подсветка html синтаксиса в любых условиях, остальное менее важно.
    • 0
      Вижу что со мной не согласны, пожалуйста, прокомментируйте вашу точку зрения (меня просто очень эта тема волнует, я всегда стремлюсь к тому чтобы код был максимально простым и понятным)
      • +1
        Ну а что вам ответить?!
        В большенстве проектом приходится решать сложные задачи, которые не покрываются возможностями шаблонизатора. В Смарти для этого нужно тупо лезть в код и дописывать (и никакого ООП). Тут же все можно изменить через наследование, компоненты разнесены по задачам. Посмотрите остальные библиотеки из проекта компонентов Симфонии, там принцип такой же. Для этого и вводили в PHP ООП. Если вам этого не понятно, то я даже не знаю.
        Также никто вам не мешает написать маленький класс со стат методами, который будет оберткой для Twig.
      • +1
        Не всегда «собрано в одном файле/классе» == «просто и понятно».
        Имхо, в большинстве случаев как-раз наоборот — видишь название класса и понимаешь за что он отвечает. И, зная это, не нужно тратить врремя на изучение всех 3х мегабайтов цельного класса/файла для того чтобы подсмотреть один единственный метод
  • 0
    Спасибо за перевод! Разрешил проблему на чет написания своего шаблонизатора. Счтаю правильным всю обработку вести в классах возврашая готовыи результат. Так как я сам программирую и верстаю код, в хтмл фаиле все удобно и понятно, простота и ничего лишнего.
  • +4
    Мне, кажется, автор не учитывает, что все шаблонизаторы изначально не создавались монстрами, а тоже были аккуратными, маленькими и быстрыми. Но по мере наращивания функциональности, они всё разрастались и разрастались, памяти ели всё больше, работали всё медленнее.
    Боюсь, что через несколько лет развития Twig, когда он догонит по функциональность Smarty, он станет и таким же медленным как Smarty.

    И второе, о целесообразности шаблонизаторов в целом. Я тоже когда-то подрабатывал верстальщиком. Так вот я не знаю ни одного верстальщика, который знает какой-либо синтаксис шаблонов, если он конечно не программист (можете сами проверить на фрилансе сколько верстальщиков знают Smarty). Даже XSLT мало кто знает. Так что вёрстку в шаблоны всё равно приходится переделывать программисту. И какой смысл тогда делать промежуточную надстройку? Мы только заставляем программиста учить ещё один язык, который ещё ограничивает его.
    Так что я за чистый PHP (или близкий к чистому) в шаблонах!
    • +3
      Лично я не уверен что Твиг будет стремительно расти в масштабах. Все что нужно Фабиену для его проектов там уже есть :)
      А по-поводу верстальщиков — как я отвечал на комментарий предыдущего поста, они все-таки есть.
  • +2
    1. экранирование должен определять не программист и не верстальщик, а _формат выходящего документа_. для примера посмотрите как сделано в xslt — куда бы я не вывел значение переменной она будет правильно заэкранирована. отсюда вывод: шаблонизатор должен на выходе получать не строку, а модель документа, которая уже может быть сериализована в строку.

    2. функция преобразования пхп-шных структур в хмл — занимает 20 строчек. тоже мне проблема великого масштаба…

    3. применение xslt web-safe-subset позволяет выносить применение xslt на клиента, что позволяет не думать о скорости шаблонизации вообще (для тех, кто в танке — юзерам не надо делать по 100 шаблонизаций в секунду)

    4. xslt — это неотключаемая песочница. ибо нефиг.

    5. xslt — это громоздкий синтаксис, поэтому лучше сделать свой шаблонизатор, но с компиляцией в xslt, а не php ;-)

    • –1
      1. Модель документа разве не должна подаваться на вход шаблонизатора? :)

      2. У меня она занимала когда-то вообще 4:
      requery_once "Smarty.php";
      smarty=new Smarty;
      smarty->assign('vars', $vars) ;
      XML = smarty->fetch('main.tpl');

      Как-то так :) Сейчас бы по другому написал, на чистом PHP, как пишу HTML/xHTML/RSS/e-mail шаблоны сейчас.

      3. С ИЕ6 работать будет? (гугл про web-safe-subset ничего не знает, только ваш коммент :)

      4. ничего не скажу, не в теме

      5. Оригинально :) Заменить 0,1 шаблонизаторов (чистый PHP :) ) на 3 (данные в XML, верстку в XSLT, XML+XSLT в HTML)?

      • 0
        1. на вход подаётся модель предметной области (коллекции, объекты, свойства), на выходе — модель документа (элементы, аттрибуты)

        2. у меня вообще одну: $this->_core->print_xml( $anyStruct )

        3. будет. ие самым первым внедрил поддержку хслт. я его только вчера придумал. ^^' но он довольно просто вычисляется экспериментально…

        4. шаблонизатор тут один — по серединке. остальное — трансформеры форматов. [php struct] -/xmlizer/-> [dom document] -/xslt/-> [dom document] -/serializer/-> [string]
        • 0
          1. Можно пример небольшой? Действительно интересно, вроде все слова понятны, а в голове не укладывается: элементы и атрибуты документа — это разве уже не готовый документ?

          2. Видимо эта функция 20-30 строк, но вот тоже не врублюсь — конкретную структуру вписать-то можно в 20-30 строк (если она не десятиэтажная), но ведь структуры в реальной жизни разные и в XML они конвертятся по разному, грубо говоря разные DTD. У одной имя свойства — это атрибут будет, у другой значение элемента, у третьей вообще значения не имеет имя свойства, а надо брать тип структуры или имя переменной.

          3. Странно, по-моему как раз в ИЕ я не смог ничего вразумительного добиться лет 4-5 назад, еще под PHP4, спасибо, буду знать, что это возможно. надеюсь, что с FF2 и Opera 9 проблем тоже не будет.

          4. Чуть-чуть яснее стало, почему я мало понимаю :) я собирал именно текстовый XML, который шел на XSLT-процессор, то есть XML у меня был не форматом, а полноценным представлением предметной области, а XSLT статический на основе HTML верстки, и потом получал с его помощью другое представление.

          P.S. Терзают меня смутные сомнения, что когда я пытался пару проектов перевести со Smarty на XML+XSLT, то где-то сделал серьезную ошибку в проектировании. Больше всего похоже на плохой «выбор DTD» в XML — пытался сделать его наиболее полно отражающим предметную область (постоянно сталкиваясь с ограничениями XML типа, что атрибуты должны быть однострочные) и тут же отражающие навигацию сайиа и т.п., не задумываясь как его буду получать из уже существующих PHP-структур, и как конвертить его в HTML
          • 0
            1. дом — объектная модель документа — это такая древовидная структура в памяти. вообще, да, для хслт на вход тоже подаётся дом. главное тут то, что при сериализации текст содержащийся в аттрибутах и текст содержащийся в обычных текстовых узлах заэкранируется по разному в соответствии с правилами хмл/хтмл и целевой кодировкой.

            2. это всё не нужно… главное — чтобы преобразование было однозначным и без потерь, тогда уже в шаблонах всё замечательно разруливается.
            проще на примере показать…
            структура: smileg.akmedia.ru/?source:action:get.php
            хмлизатор: smileg.akmedia.ru/?source:printer:xmlize.php (криво, но мне хватает)
            получаемый хмл: smileg.akmedia.ru/?qwerty

            3. там есть нюансы… в ФФ на выходе получается только xhtml-dom а это не очень удобно…

            5. я с этим не заморачиваюсь — у меня просто нет аттрибутов во входном документе %-) в хслт с таким документом работать даже проще ;-)
  • 0
    надеюсь кому-нибудь пригодиться — twig.kron0s.com/
  • 0
    А кто-нибудь уже использовал Twig на больших и нагруженных проектах или слышал об использовании в той или иной компании/проекте?

    Можете указать конкретные проекты, нагрузки, размеры команд, сложности, с которыми столкнулись?
    Проект начинался на Twig или переходили с чего-то?
    Как разработчики справляются с обучением?
    Занимаются ли верстальщики написанием/правкой шаблонов или только программеры?

    Серьезные ли проблемы дает отсутствие обратной совместимости, например между версиями 0.9.6 и 0.9.9?
    Знает ли кто, предполагается ли обратная совместимость в следующих версиях?

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.