20 ноября 2009 в 19:39

Перевод: Шаблонизаторы в PHP перевод

PHP*
Первод статьи, автором которой является Fabien Potencier, ведущий разработчик и идеолог Symfony. Статья поднимает обсуждение о шаблонизаторах PHP в целом и представляет Twig — быстрый и функциональный шаблонизатор.

-----------------------------------------------------------------------
Итак, вы считаете что PHP это уже шаблонизатор? Так думал и я… и очень долго. Но недавно я передумал. Несмотря на то что PHP может использоваться как шаблонизатор, его синтаксис ужасен для этих целей.

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

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

И когда я несколько дней назад спросил о лучших и популярных шаблонизаторах на PHP в Твиттере, некоторые, естественно, ответили «сам PHP». Это было вполне предсказуемо, ведь несколько недель назад я бы ответил так же.

Так почему же PHP (уже) не является удобным шаблонизатором?

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

Шаблонизаторы стремительно развивались начиная с 1995 года, когда вышел первый релиз PHP/FI:
<!--include /text/header.html-->
 
<!--getenv HTTP_USER_AGENT-->
<!--ifsubstr $exec_result Mozilla-->
  Hey, you are using Netscape!<p>
<!--endif-->
 
<!--sql database select * from table where user='$username'-->
<!--ifless $numentries 1-->
  Sorry, that record does not exist<p>
<!--endif exit-->
  Welcome <!--$user-->!<p>
  You have <!--$index:0--> credits left in your account.<p>
 
<!--include /text/footer.html-->


И значимым фактом является то, что PHP не поддерживает множество возможностей современных шалонизаторов.

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


Ниже описано то что я хочу видеть в современном шаблонизаторе:

Краткость

PHP многословен. Только для того чтобы просто вывести переменную необходимо не менее 14 символов (нет, использование более компактного <?= непреемлемо):
<?php echo $var ?>


И PHP становиться нелепо многословен при необходимости экранировать вывод (да, экранирование данных полученных из небезопасного источника является обязательным)
<?php  echo htmlspecialchars($var, ENT_QUOTES, 'UTF-8') ?>


Сравнити это с двумя примерами написанными на Django:
{{ var }}
{{ var|escape }}


Синтаксис ориентированный на шаблоны

По больше части это дело вкуса, но шаблонизаторы должны иметь красивые решения частых случаев. Для примера предположим, что необходимо отобразить массив и вывести текст по умолчанию, если этот массив пуст. Это очень распространенный случай, но версия на PHP не очень читаема:
<?php if ($items): ?>
   <?php foreach ($items as $item): ?>
    * <?php echo $item ?>
  <?php endforeach; ?>
<?php else: ?>
    No item has been found.
<?php endif; ?>


Версия на Django гораздо лучше — спасибо конструкции else для тега for:
{% for item in items %}
  * {{ item }}
{% else %}
  No item has been found.
{% endfor %}


Повторное использование

PHP развивался с учетом возможности повторного использования кода. Начиная с 5-й версии реализация объектов сделала шаг вперед и, после того как в следующей версии будут поддерживаться типажи, мы получим язык программирования удовлетворяющий наши требования. Я действительно рад всем этим изменения т.к. это помогает мне писать программы лучше, но это не имеет значения когда все что тебе нужно — это написать шаблон.

В Django ввели наследование шаблонов несколько лет назад, пытаясь повторить наследование классов в шаблонах:
<!-- base.html -->
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <head>
    {% block head %}
      <link rel="stylesheet" href="main.css" />

    {% endblock %}
  </head>
  <body>
    {% block content %}{% endblock %}
  </body>
</html>
 
<!-- index.html -->
{% extends "base.html" %}

 
{% block head %}
  {{ block.super }}
  <link rel="stylesheet" href="main.css" />
{% endblock %}
 
{% block content %}
  Index content
{% endblock %}


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

Безопасность

Я не говорю что PHP небезопасен. Но я хочу сказать что экранирование переменных в шаблоне это просто кошмар, как и продемонстрировал ранее:
<?php echo htmlspecialchars($var, ENT_QUOTES, 'UTF-8') ?>


Конечно, вы можете написать свою функции и сделать ее котороче, но это не то о чем я говорю:
<?php echo e($var) ?>


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

Насколько я знаю, Symfony был самым первым фреймворком поддерживающим автоматическое экранирование в шаблонах (2006); и все основные фреймворки пошли тем же путем: в Django по умолчанию включено экранирование начиная с версии 1.0, и в Ruby on Rails это тоже появится с версии 3.

Включенное автоматическое экранирование так же означает что аудировать(?) приложение гораздо проще. Взгляните на примеры с отключенным экранированием:
{% autoescape off %}
  {{ object.as_html }}
{% endautoescape %}
 
{{ object.as_html|safe }}
 


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


Режим «Песочницы»

Эта возможность особенно необходима в том случае когда пользователи могу сами редактировать шаблоны сайта (например, из системы управления сайтом). Это не является необходимость, однако бывает важно. Исполнение шаблонов в «песочнице» означает возможность ограничить то что может быть выполенно: методы/функции которые можно вызывать, теги которые можно использовать и т. д.

Ни у PHP, ни у Django нет такого режима, так что продолжайте читать эту статью для дальнейшего объяснения этой секции.

Альтернативные шаблонизаторы для PHP


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

На PHP написан миллион шаблонизаторов, я тестировал только самые «популярные». И т. к. я их не использую мной могут быть допущены ошибки использования того или иного шаблонизатора.


Smarty и Smarty 3

Это то что первым пришло в голову. И сам язык шаблонов Django был «навеян» Smarty. Smarty это стандарт де-факто для PHP.

Hello {$name|escape}
{section name=item loop=$items}
  {$items[item]|escape}
{/section}


Но у Smarty есть ряд проблем:
  • Не объектно-ориентирован
  • Нет наследования шаблонов
  • Нет «песочницы»
  • Нет автоматического экранирования

Насколько я понимаю, Smarty 3 вот-вот выйдет и достаточно сильно улучшит состояние:
  • Объектно-ориентированная архитектура
  • Автоматическое экранирование
  • Наследование шаблонов

Я протестировал обе версии, но скорость работы достаточно низкая (в конце имеется информация о тестах)

PHPTAL

PHPTAL очень приятный проект, использующий синтаксис шаблонов Zope. Очень хорошо спроектирован, имеет большое количество возможностей, но не умеет работать с не-HTML шаблонами, что может стать проблемой, если вы хотите использовать один язык шаблонов также для писем и RSS лент.
<?xml version="1.0"?>
<html>
  <body>
    Hello <span tal:content="name" />
    <ul tal:repeat="item items">
      <li tal:content="item"></li>
    </ul>
  </body>
</html>


Еще я думаю что синтаксис может оказаться непонятным веб-дизайнерам, особенно при использовании расширенных возможностей, таких как наследование шаблонов:
<html metal:use-macro="layout.xml/main">
 <body metal:fill-slot="content">
   Hello <span tal:content="name" />
   <ul tal:repeat="a array">
     <li tal:content="a"></li>
   </ul>
 </body>
</html>

<html metal:define-macro="main">
  <metal:block define-slot="content"/>
</html>
 

Одним из важных достоинств можно назвать автодополнение в среде разработки и гарантировано «правильно сформированный» HTML код.

eZ Components Templates

Компонент шаблонов в составе eZ Components так же предоставляет очень удачный языком шаблонизатора. Здесь присутвуют почти все возможности шаблонизаторов… даже чресчур, если вы хотите знать мое мнение:
{use $name}
{use $items}
Hello {$name}
{foreach $items as $item}
 * {$item}
{/foreach}

Наследование шаблонов не поддерживается, и меня беспокоит скорость работы. Это самая медленная библиотека что я тестировал, и сильно медленне остальных.

Dwoo

Dwoo — это, прежде всего, интересный проект. Он позиционирует себя как альтернативу Smarty. И их работа стоит внимания:
<html>
  <body>
    {block "content"}{/block}
  </body>
</html>


{extends "layout.tpl"}
 
{block "content"}
  {include("basic.tpl")}
{/block}


Dwoo подражает Smarty, но также вносит и свои дополнения, например, наследование шаблонов, и работает гораздо быстрее Smarty.

К сожалению, у Dwoo нет «песочницы» и ядро библиотеки недостаточно гибкое.

Calypso

Calypso это реализация шаблонизатора Django на PHP. Я упоминаю о нем т.к. он клон Django и на него ссылались в Твиттере. Но сам автор считает что его реализация неудачна.

Twig

Когда я приступил к поиску PHP шаблонизатора, я сосредоточился на библиотеках копирующих поведение Django. Спустя несколько часов «гугления» был найден Twig. Его автором является Armin Ronacher, известный по проекту of Jinja (шаблонизатор для Python). Несомненно я испытываю крайнее уважение к Армину за его замечательную работу над Jinja. Twig скорее похож на Jinja, чем на Django, как описано в реализации.

Он написал Twig в 2008 году для платформы блогов Chypr. Но больше не возвращался к разработке и больше занимался разработкой на Python.

Когда я взглянул на код, я сразу понял что это то что я ищу. Главное отличие от Calypso в том что Twig компилирует шаблоны в обычный PHP-код. Я начал использовать эту библиотеку и в конце этой недели спросил у Армина не желает ли он дать своему проекту новую жизнь. Его ответ был полон энтузиазма, и я приступил к изучению кода. Моя версия сильно отличается от версии Армина, но «лексер» и «парсер» практически оригинальные.

Я потратил всего несколько дней на работу над кодом, но я уже горжусь результатом и думаю что пора показывать библиотеку публично. Вчера я написал документацию и сделал простой сайт. Осталось еще много работы: закончить документацию, добавить тесты и PHPDoc; но код уже целостен и функционален:
  • Встроенное наследование шаблонов (шаблоны компилируются как классы)
  • Автоматическое экранирование (отсутствуе дополнительное время на запуск — все делается во время компиляции)
  • Очень безопасный режим «песочницы» (список допустимых тегов, фильтров и методов которые разрешены в шаблоне)
  • Расширяемость: вы можете переписавать все что угодно, даже функции ядра, написав расширение; так же можно маниаулировать AST (Abstract Syntax Tree) (?) перед компиляцией. Используя эти возможности вы можете создат даже свой собственны язык — DSL (Domain Specific Language), ориентированный на ваше приложение.

Несмотря на то что Twig самый функциональный шаблонизатор, он еще и самый быстрый.

Библиотека Время (сек) Память (Кб) Шаблонов в секунду
Twig 3 1 190 3 333
PHPTAL 3.8 2 100 2 632
Dwoo 6.9 1 870 1 449
Smarty 2 12.9 2 350 775
Smarty 3 14.9 3 230 671
Calypso 34.3 620 292
eZ Templates 53 5 850 189

Я тестировал простые шаблоны содержащие 1 вывод и итерацию трех элементов, декорируя простым макетом. Время — среднее для 10 запусков; состоящее из 1 компиляции и 10 000 отображений (рендеринга). Для библиотек, не поддерживающих наследование был использован шаблон подключающий шапку (header) и подвал (footer) отдельно и, в библиотеках не поддерживающих автоматического экранирования, экранирование было выполнено вручную.


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

Библиотека Память без компиляции (Кб)
Twig 383
PHPTAL 598
Dwoo 1 645
Smarty 2 1 634
Smarty 3 1 790
Calypso 614
eZ Templates 2 783


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

-----------------------------------------------------------------------
Это мой первый перевод. Не только для хабра, а вообще. Поэтому приветствуются комментарии не только про шаблонизаторы и Twig, но и про сам перевод.

Перевод: Подведение итогов.
+32
12502
140
zhekanax 29,9

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

–1
Fesor, #
Пометили б пост как перевод.

Во вторых все рассматриваемые шаблонизаторы мне не понравились. Twig достаточно неплохой вариант но я от него отказался.
+2
zhekanax, #
Иконка поста говорит уже что это перевод, можно повториться — не сложно
0
Fesor, #
простите… после рабочей недели глаза перестают различать мелкие иконки)
0
veter, #
А в пользу чего отказались?
НЛО прилетело и опубликовало эту надпись здесь
+2
sindrom, #
Чувствую, скоро здесь будет холивар…
+4
zhekanax, #
А холивар на оригинале уже закончился и даже итоги подвели. Которые тоже можно будет перевести если кому-нибудь будет интересно.
0
CAH4A, #
Итог холивара?
Да, это очень интересно. :)
0
zhekanax, #
НЛО прилетело и опубликовало эту надпись здесь
+1
zhekanax, #
habrahabr.ru/blogs/php/76021/ повторюсь, ради уведомления на почту
0
chetzof, #
Ну, кто первый начинает?
0
Ewg, #
> PHP многословен.

Автор, наверное, даже о не знает.
0
zhekanax, #
о чем, простите?
–9
Zibx, #
Поубивал бы за такое:
<?php if ($items): ?>
   <?php foreach ($items as $item): ?>
    * <?php echo $item ?>
  <?php endforeach; ?>
<?php else: ?>
    No item has been found.
<?php endif; ?>
+1
Fesor, #
согласен. При написании своего компилятора 2 часа убил на собственно компиляцию и еще 4 на «уборку» того что этот компилятор натворил.
+3
Hint, #
Можно конкретнее? За что именно то?
+1
Hint, #
Убейте всех тех, кто использует Symfony.
–8
Zibx, #
За endif, endforeach. Напоминают о некоторых иных языках, при этом в пхп есть кошерные фигурные скобочки. Хотя это ещё пол беды. Какой смысл в инлайновом коде кроме нагрузки на интерпретатор?
НЛО прилетело и опубликовало эту надпись здесь
+3
sskorykh, #
Часто доводилось чужой код разгребать? Мне вот часто. Так вот замечу, что код со скобочками ощутимо сложнее разгрести по причине их полной неинформативности.
+6
pipboy, #
Использование PHP в качестве языка шаблонов имеет право на существование — достаточно читабельно, а также оптимальный вариант по быстродействию.
0
CAH4A, #
Ну если идёт компилирование из шаблона в php-native — то выиграша в скорости почти нет.
–1
zhekanax, #
т. е. автор вас не убедил, как меня? и вы не согласны что есть способы лучше? :)
0
taliban, #
как альтернатива пхп не плох, а что лучше а что нет, каждый выбирает для себя
+1
Treg, #
Как раз такие конструкции намного удобнее применять в шаблонах, чем скобки, и за это разработчикам php большой и жирный плюс.
+1
jiexaspb, #
почему нету PHP Blitz в тестах?
+1
Koc, #
Наверно потому, что он — расширение на C, в отличие от того же Smarty
+4
Solopov, #
наверное потому, что тогда цифры были бы другие, а тут вроде как новый шаблонизатор всех победил…
0
casey, #
А никто не знает, есть ли Blitz под PHP 5.3?
+1
max_m, #
blitz уже давно под 5.3 работает
+1
zhekanax, #
я думаю что автор сказал бы что в Blitz нет наследования и режима песочницы :))
0
DurRandir, #
И СTPP2 нет. Вот незадача, они препятствуют концепции «код в шаблонах» и рвут всех по производительности :)
+3
boolive, #
Зачем в шаблоне фильтровать/экранировать данные? Незачем ответственность за безопасность перекладывать на верстальщика.
+1
Bal, #
Чтобы логика представления была в виде, а не в контроллере. Иначе замена вида может потянуть за собой замену представления в контроллере.
–1
taliban, #
можно отфильтравать данные перед отдачей их шаблону, благо бьекты могут это делать в методах перед выдачей, да и array_map никто не отменял
0
egorinsk, #
Почитайте на досуге про MVC что ли.

Представьте. у вас половина переменных — текстовые строки. а другая — HTML- код (выводится без эскейпинга). И что, вы предлагаете в контроллере пропускать часть переменных (руками указывая каких!!) через array_map()? Что за бред?
–1
taliban, #
я могу отфильтровать все в модеи, у меня есть фильтры для этого, которые делают всю грязную работу и возвращают чистые строки, которые спокойно можно использовать в виде

зы: почитайте на досуге про MVC, только почитайте нечто более нужное чем введение из википедии
+1
egorinsk, #
Вы в * модели* делаете HTML-эскейпинг??? А если завтра вам надо будет добавить вывод в json или plain text, вы все методы во всех моделях продублируете, да? $model->getAllForHTML(), $model->getAllForJSON() и так далее?

И как тогда, если данные эскейпятся, получить «чистые» данные? Например, для записи в какую-нибудь БД, отправки по какому-нибудь протокол, или еще зачем-нибудь.

0
taliban, #
во-первых есть замечательный паттрен: фабричный метод… дублирования методов не будет, во вторых допустим Вам приходят в шаболн данные, вы что будете ставить кучу ифов чтоб проверить это HTML, и его надо экранировать, либо это JSON и тут надо обработать их без экранирования?
я в любом случае получу чистые данные, при выводе в шаблон этим занимаются фильтры, при записи в бд этим занимаются методы для записи в бд…

зы: эскейпинг — частный случай, я в модели _привожу данные в нужный мне вид_
0
egorinsk, #
Ну я например знаю, что title у меня — plain text, а content — это HTML :) Впрочем, большинство данных берется из БД, а значит является plain text, который надо эскейпить.

Если же вам приходит большой массив данных, например таблица, содержащая колонки и с обычным текстом, и с HTML, то к ней должен прилагаться массив с описанием типов данных в каждой колонке :)

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

Форматирование и оформление данных (типа вывод даты в формате «Сегодня, 2 часа назад») должен делаться в Виде, как иначе-то? И зачем плодить для этого какие-то фабрики?

> во вторых допустим Вам приходят в шаболн данные, вы что будете ставить кучу ифов чтоб проверить это HTML, и его надо экранировать, либо это JSON и тут надо обработать их без экранирования?

Для разных форматов вывода (HTML, json и прочее) используются разные шаблоны (а иногда и разные компоненты View).
–1
taliban, #
вы записываете в бд не обработанные данные и потом их чистите при выводе? это верх тупости, если я читаю данные из бд, значит они уже обработаны и в них нет ничего лишнего, единственные обрабатываемые варианты — формы, там ковычки могут все испортить, но конкретно в моем случае я использую зенд, и за вывод элеменотв отвечают соответствующие классы

в виде форматирование данных типа «Сегодня, 2 часа назад» элементарно справится набор функций/классов, это к делу не относится (хотя тоже своего рода модели)

для разных форматов и я могу использовать разные шаблоны

может быть я неправильно понял, или вы на самом деле говорите про htmlentities? если да, то мы говорим о разных вещах

+2
egorinsk, #
> вы записываете в бд не обработанные данные

Я записываю данные в БД, кеш и т.д. в их исходном виде, как есть, и та же кавычка там хранится как кавычка (") а не & quot; Что вы имеете в виду под «если я читаю данные из бд, значит они уже обработаны», я не понял.

Естественно, в модели при записи данных в БД могут проверяться разные условия, например тип данных, длина, допустимые символы и т.д.

Про форматирование данных в шаблоне — я имею в виду, что и htmlentities, и date_format/number_format делаются там.
+1
DmitryKoterov, #
Правильно товарищ говорит. View должен сам квотить данные, которые в него приходят, автоматически. Иначе получается опасность XSS.
0
taliban, #
меня бесят строки типа {$item|htmentities|dateformat:"%m/%d"|default" "} это ведь все поидее экранирование? я имею ввиду что проще сделать модельку для вьюв
<?php Date::format( $item, Date::SHORT ) ?>
0
zhekanax, #
Fabien как раз и говорит о том что оно должно быть включено по-умолчанию. Имея возможность местами выключать.
0
taliban, #
уже делали такую штуку, называется magic_quotes в итоге строки получались на подобии «qwe\\\»asd" потому как программа не всегда знает когда это нужно а когда нет, программист лучше знает места где это надо и реализовать в «хелпере/функции/методе/модели» лишний раз htmlentities не составит большого труда
0
taliban, #
да, строчка подкачала, я имел ввиду такое: «qwe\\\«asd»
0
taliban, #
блин, ну я думаю вы меня поняли :)
0
zhekanax, #
Эскейпить по-умолчанию, выключая в ненужных местах. Мне такой вариант больше нравится, как и автору.
0
taliban, #
может я не прав, но включение и отключение экранизации при изменении шаблода другой программист может не заметить, а явную экраницацию трудно пропустить, может некоторым это покажется мелочью, но когда таких мелочей больше, это начинает сбивать с толку и приводить к глупым ошибкам
0
develop7, #
Слушайте, ну вот не проще разве включить экранирование по умолчанию, чем к каждой переменной в шаблоне приписывать |escape? Или вам лично не лень?
0
taliban, #
лень конечно, но вдруг мне _нужно_ будет что-то сделать с данными в модели и там я их экранирую, не получится кака?
0
develop7, #
Если экранировать в модели — безусловно получится. Но разве я предлагал именно такой вариант?
0
taliban, #
я не о том, если мне нужно вдруг проделать какие-то махинации с данными, я экранирую, делаю махинации и в шаблоне не экранирую, в итоге получается что в шаблоне придется отключать экранирование, и опять же возвращаемся к каменту выше: «… а явную экраницацию трудно пропустить»
0
develop7, #
А я не экранирую в модели, а в шаблоне экранирую по умолчанию. В каких-то особых случаях экранирование отключаю (когда уверен, например, что здесь точно не будет XSS или ещё чегонить в этом роде).
+1
DmitryKoterov, #
Вы очень хороший пример привели, с magic_quotes, но, кажется, не в том смысле, который в него вкладывали. Это как раз пример о том, что не надо делать экранирование в модели, потому что модель не знает, где будут выводиться данные и в каком формате. Ну а к автоквотингу в шаблоне пример с magic_quotes имеет малое отношения.
0
VolCh, #
Не уверен, что правильно это реализовывать в модели, скорее просто хелпер, который относится все-таки к отображению.
0
taliban, #
какая разница как называть модель? модель, хелпер, фильтр — это все отдельно взятая еденица кода которая реализует логику, дабы не загромождать контроллер и вид… по сути это и есть фильрация данных, и про нее я и говорил, мы просто с egorinsk неправильно поняи друг друга
0
VolCh, #
Ну назвать-то можно как угодно, главное сознавать, что форматирование данных это функция вида, а не контроллера или модели ;)
+1
taliban, #
да, это функция вида, однако ниже человек говорил что вид != шаблон, и я его поддерживаю, в шаблоне должно быть как можно меньше логики. надо строить архитекруту так, чтоб шаблоны могли обрабатываться банальным str_replace, если это так, тогда архитекрута идеальна, ну это мое мнение :)
0
VolCh, #
Ну да, шаблон часть вида :) Но вот слабо представляю, как через str_replace сделать вывод таблицы неизвестных размеров, так чтобы весь HTML код был в одном файле :-/
0
taliban, #
// controller
$this->view->userList = $objModel->getUserList();

//model
// бла бла, бд итд
foreach($users as $id => $user)
{
$objRow->add($user['nickName']);
$objRow->add($user['email']);

$objRow->addAction(Models_Row::EDIT, $id);
$objRow->addAction(Models_Row::DELETE, $id);
$objTable->addRow($objRow);
}
return $objTable->render();

// template
{$userList}

как-то так
0
taliban, #
в данном случае на вид ложится обязанность структурировать шаблоны, следить за вложенностями в зависимости от контроллера, а вся логика ложится на модели
я не говорю что так нужно делать, я говорю что так _можно_ делать, и ничего плохого в этом нет, дизайнер не заморачивается в логике, он пишет только классы цсс, которые влияют на внешний вид
0
taliban, #
если кто-то слишком строго относится к моделям, можно вместо модели использовать хелпер вида, это не важно, всеравно логика не изменится
0
egorinsk, #
Разница есть, модель — компонент для работы с данными предметной области (дата — это не часть предметной области), в первую очередь, а хелпер — это вспомогательный компонент View. Переименовывать их не стоит, так как возникает непонимание ))
0
egorinsk, #
> это ведь все поидее экранирование?

Экранирование — это htmlspaecialchars(), остальное — это форматирование :)

В вашем примере — можно конечно сделать хелпер date_format_for_html, но по-моему, проще переименовать хелпер htmlspaecialchars() в «e» и тогда все будет проще: {$item.title|e}, {$item.date|date:"%d.%m"|e} (хотя дату эскейпить необязательно). По моему, так это лучше, чем лишние скобки и знаки вопроса.

А с автоквотингом — даже |e писать не надо, просто {$item.title} :)
0
taliban, #
если дело только в скобках то это глупо, надо смотреть с точки зрения вида а не с точки зрения написания 4-х лишних символов
0
egorinsk, #
Так пайп выглядит очень даже хорошо :) Сразу видно, что берется переменная, пропускается через один фильтр, потом другой, а представьте вызов например 4 функций друг за другом.

И мне не нравятся лишние символы, {$title|default:""|e} (по моему субъективному мнению) в разы лучше [php htmlspecialchars($title? $title: '', ENT_QUOTES, 'utf-8'); ]
0
taliban, #
Да, Вы правы, в примерах которые Вы показали, действительно шаблонные методы смотрятся аккуратней, вы не учли что так не делают, пишут хелперы/функции, ведь никто не мешает сделать так:
<?php Filter::escape( $title ) ?> все понятно и красиво, меня не напрягает написать 5 лишних символов, всегда можно макрос написать и поставить горячие клавиши, а еще я могу сделать так:
<?php Customize::description( $desc ) ?> и у меня появится ровно ХХ символов описания со ссылочкой «далее...», причем меня не будет волновать utf8 это или нет, нужно ли экранировать, ставить 3 точки или нет, все внутри, и даже больше, все в конфиге… такое можно сделать и в шаблонизаторе, безусловно, но если в итоге будет тоже самое но на 5 символов меньше, то я не вижу разницы
0
egorinsk, #
А меня — напрягает. Понятно, что есть сокращения в редакторе, и т.д., но тут именно выглядит код по-разному. На php я пишу контроллеры и модели. а вот шаблоны — на отдельном языке :)

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

И мне почему-то интуитивно не нравится эта визуальная каша из тегов и скобок [?php, ну некрасиво по-моему.

Хотя я видел шаблонизатор (serpent), который просто заменял [?php и [?php echo на скобки, а сам код оставался на php.

В любом случае. в php нет наследования шаблонов, так что мне не подходит.

Хотя, наверно это — дело вкуса, если у вас нормаьно получается на php — пишите на php.
0
taliban, #
>что завтра вам понадобится такой же, но без эскейпа, или еще что-нибудь там надо поменять будет — тогда ваш подход даст трещину
если вам надо чтоб модель возвращала разные данные, вы делаете либо еще один метод, либо еще один парамерт, так же можно сделать в фильтрах

я пишу на смарти =) я не говорил что шаблонизаторы — плохо, я говорил что пхп — не плохо
0
taliban, #
а еще вот сюда взгляните, очень хороший пример обработки данных перед отдачей их в шаблон, там вообще в шаблоне не надо логики
habrahabr.ru/blogs/php/75901/#comment_2208033
0
taliban, #
вы кстати никогда не думали что вид тоже может использовать модели, только для своих целей (опять же «Сегодня, 2 часа назад»)
0
boolive, #
Если бы вы меньше полагались на книжки про MVC и старались сделать реальное разделение логики от данных, то не делали бы таких категоричных выводов. Правильно, если вы всю логику представления реализуете в шаблоне, то в нем и фильтром и всем остальным будете заниматься, следуя такому подходу, вы потом захотите больше алгоритмических возможностей в шаблоне, от чего появляются мега шаблонизаторы, точно также пхп развивался.
0
egorinsk, #
Ну я не только полагаюсь на книжки, я свои велосипеды пишу, и голову не раз уже ломал в поисках решений для разных частей этого велосипеда, чтобы например удобство разработки сочеталось с нормальной производительностью.

В View — логика вывода данных, которые он получает от Контроллера (ну или Модели, если используется такая схема), соответсвенно все форматирования и эскейпы стоит делать именно здесь. Если вам *принципиально*, чтобы не использовался код в шаблоне — разбиваете View на код и на шаблоны. В Controller — логика обработки запросов пользователя, вызов всех остальных компонентов, нужных для вывода страницы, что тут сложного?

Ну а Model содержит логику хранения, получения, обновления данных предметной области.

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

Мега шаблонизаторы (типа монстра смарти) появляются из-за попыток сделать универсальное решение на все случаи жизни с возможностью замены чего угодно на что угодно, а не от этого.
0
boolive, #
Почему тогда такая категоричность с фильтром данных именно в шаблоне, если сами знаете, как надо бы делать (в коде View)?
0
egorinsk, #
Потому что я оказался в легком шоке от идеи эскейпить данные прямо в модели. Что касается разделения View на код/шаблон — я лично против, так как мне неудобно править 2 файла вместо одного. Проблемы не умеющих программировать верстальщиков меня не интересуют.
0
boolive, #
Спасибо, теперь понятно стало, что каждый о своем думал))
+1
boolive, #
Представление — это отдельный компонент системы со своей логикой предназначенной для подготовки данных для рендеринга в соответствующий формат, обычно в html. Шаблон — это как скин у десктопных программ — ему не нужна логика. Почему вы считаете шаблон видом? Если в шаблон запихивать логику, то рано или поздно рождаются монстры типа смарти со своим фактически языком программирования. А у нас какая цель — чтобы шаблон просто отобразил то, что ему дали.

На сегодняшний день ещё нет идеально реализованного «вида», а ведь поверьте, через детализацию шаблонов в них даже циклы и условные операторы не нужны будут.
+1
boolive, #
Поэтому разница между <?=$v['head']?> и %v[head]% в паре символов и в скорости. Лучше выбрать скорость, так визуальная разница ничтожна.
0
janson, #
Использование коротких тегов для PHP не самый лучший вариант.
Отсюда первый вариант будет выглядеть так:
<?php echo $v['head'] ?>

Уже не так компактно, как хотелось бы.

Опять же, если шаблон представить в виде skin, то на каждый вариант логики view надо будет предусмотреть свой шаблон?

На мой личный взгляд — слишком поперенавороченно получается. =)

В любом упрощении, главное — не усложнить.
0
boolive, #
Если удастся вытащить полностью логику из шаблона, то конечно лучше применить простые вставки, типа %v[head]%, тогда мы ещё и предотвратим использование php. Когда не получается обойтись без логики в шаблоне, тогда лучше не извращаться и применять php. :)

> Опять же, если шаблон представить в виде skin, то на каждый вариант логики view надо будет предусмотреть свой шаблон?

Поэтому я говорю о детализации. Шаблоны могут быть вплоть до минимальных единиц информации в системе, в моём случае – это сущности. В реальности может получиться, что не потребуется создавать шаблон для новости, так как новость соберется из шаблонов её заголовка и текста. Избавится от необходимости логики в шаблоне реально, и при этом иметь супер гибкость. Всё зависит от архитектуры системы и вопрос этот не прост для обсуждения здесь. Конечно, компонент представления получится не легким, но это как с детализацией трехмерной графики – отличная картинка за большее процессорное время. Во всяком случаи мы не анимацию делаем, и может использовать многоуровневое кэширование.
0
Treg, #
Шаблон это не трафарет, и в нем должна присутствовать логика вывода. Гораздо проще и удобнее в шаблон передать объект и уже там определять, какие свойства выводить. Иначе придется править в 2х местах: сначала определять — что передавать в шаблон, а потом как это выводить.
0
boolive, #
Оно это так, мне тоже так удобней, но это приводит к нарастанию логики внутри шаблона, от чего многие хотят избавится, и думают, что создав отдельный слой — шаблонизатор, всё будет гуд, но это утопия. Если нужно избавится от логики в шаблоне, то нужно работать над архитектурой системы, над архитектурой компонента представления. Решением я вижу только в детализации шаблонов. Если же архитектура требует логики в шаблоне, то люди, не извращайтесь, используйте пхп :))
0
boolive, #
Кстати, чтоб передать шаблону объект, его ведь тоже надо подготовить, а кроме объекта может понадобится служебная информация, либо информация об объекте относительно других объектов, например порядковый номер, именование (чем этот объект является для кого-то). И поэтому образуется отдельно логика, отдельно шаблон, либо размазанная логика как в шаблоне так и в других местах системы, что не упрощает шаблонизацию.
+1
Bal, #
>Шаблон — это как скин у десктопных программ — ему не нужна логика

Логика вывода нужна обязательно. Например, выделить важную новость в списке жирным. И полного разделения на контроллер и вид тут не получить в принципе. И придётся или HTML-код, часть представления, засовывать в контроллер, или условный оператор выносить в шаблон. Я сторонник второго подхода, так как он идеологически намного чище. Видом должен заниматься вид. Даже если это требует программирования в шаблоне.

>На сегодняшний день ещё нет идеально реализованного «вида»

И не может быть. На то он и идеальный, чтобы быть нереализуемым в реальном мире на реальных задачах.
0
boolive, #
> Например, выделить важную новость в списке жирным.

Во! Полезная зацепка. Шаблон должен выбираться не только по типу объекта и, например, места — текущего адреса, а вообще по состоянию объекта, в зависимости, какие у него свойства, какое отношение с другими объектами. Это может натолкнуть на реализацию продвинутой модели данных. Эта очень интересная тема))
0
Bal, #
1. Слишком громоздко будет и неудобно. И чем больше таких параметров, тем сложнее.

2. Опять же, часть работы верстальщика переедет на программиста. Вот потребуется верстальщику ввести изменение по какому-то критерию, а в коде этого не предусмотрено. Вместо того, чтобы написать простенькое условие, придётся модифицировать код или схему.
0
boolive, #
Спорить не буду, возможно, громоздко, но ещё не проверено. По второму пункту вы просто чуток не поняли, не нужно будет писать каждый раз логику для выбора шаблона – это будет единый алгоритм выбора шаблона в соответствии с состоянием объекта, который шаблонизируем. Вопрос пока чисто теоретический, на практике ещё не понятно как провести это соответствие, ведь шаблон – это просто файл, в него либо логику пиши, либо где-то храни конфигурацию, при каком состоянии объекта использовать именно этот шаблон. От этого и возникает мысль о громоздкости, согласен. Но, думаю, довольно гибко и просто было бы — чтоб сделать отображение топиков, у которых ещё нет комментариев — достаточно создать шаблон, который будет автоматически применяться для таких топиков.
0
taliban, #
>Логика вывода нужна обязательно. Например, выделить важную новость в списке жирным.
взгляните на Zend_Form из зендовского фреймверка, это отличный пример «представления», в шаблоне обходится все без логики, только вывод формы, причем возможности вплоть до красной звездочки возле обязательного поля
0
egorinsk, #
Ох, а я вот не люблю ZF за излишнюю универсальность и разбиение на слишком крошечные компоненты. Что касается форм — в Zend отвратительно сделаны декораторы. Так как приходится в классе формы, рядом с типами полей и валидаторами писать HTML код. Это в общем плохо, так как HTML-код должен быть в шаблоне.

А так как я увлекаюсь велосипедостроением, то для себя придумал (но пока не реализовал) другое решение проблемы декорирования форм, оно выглядит примерно так:

{form data=$form}
{block 'label-for-username'}[strong]{parent}[/strong]{/block}
{block 'form-element-password'}{parent}[p class='hint']Пожалуйста, не используйте слабые пароли! [/p]{/block}
{/form}
Надеюсь код понятен, первый тег {block} декорирует label, заключая его текст в тег strong, второй добавляет абзац текста после поля «password».
0
develop7, #
Ну, не знаю, как у вас в ZL, а вот в symfony, несмотря на то, что есть возможность выплёвывать форму одним <?php echo $form ?> и как угодно кастомайзить декораторы, при вкручивании формы в свёрстанный макет этим пользоваться крайне не рекомендуется. Гораздо проще стратегически расставить в макете <?php echo $form['field…']?>, <?php echo $form['field…']->renderLabel()?>, и <?php echo $form['field…']->renderError()?>. Или я вас неправильно понял?
0
egorinsk, #
Гм, вручную? Прописывать каждое поле? Для десятков форм? Вы сдурели?

И вообще, многие моменты (вроде тех же декораторов, и не только) сделаны в свободных фреймворках из рук вон плохо, все приходится самому делать.
0
develop7, #
Ну вот у меня в предпоследнем проекте приходилось прописывать руками. Оказалось, что так проще, чем настраивать декораторы, чтобы подогнать их под свёрстанный шаблон.
0
egorinsk, #
Потому что наверно плохие декораторы, я ж говорю, из рук вон плохо сделаны.

А руками писать — не выход, в той же админке и контрольной панели могут быть десятки форм, надоест писать.
0
develop7, #
Ха. В админке-то я формы как раз echoм и вывожу. Это как раз во frontendе приходилось точечно расставлять куски формы.
–4
ArtemS, #
Наследование в шаблонах!? Вы шутите? Верстальщик не программист, он не должен знать таких вещей как наследование, а в идеальном случае и цикл, переменная и т.п.

+5
dfilatov, #
Верстальщики прекрасно знают что такое парадигма наследования, хотя бы из css. И не пользоваться этой мощью в шаблонах — путь в говнокод.
+1
ArtemS, #
Я предлагаю их избавить от необходимости знать что это. Граница вхождения опуститься. А говнокод будут писать всегда, какие бы средства не предоставлять. Я просто всегда пропагандирую принцип KISS
0
dfilatov, #
Что говнокод пишется с помощью любых средств — это несомненно. Только способствовать этому, не применяя общеизвестные практики (прикрываясь их типа сложностью), уменьшающие вероятность говнокода, это темный путь силы. Да и нет ничего сложного в наследовании, это способен понять любой верстальщик.
+2
ArtemS, #
Количество говонокода можно уменьшить лишь прокачав мозги и только.

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

С моей стороны понимайте это заботой о пользователе. Чем меньше он знает о программистских штуках тем лучше для него. И если был бы простой способ избавить шаблоны от циклов и переменных — я бы сделал это.
+1
Vertex, #
Такое чувство, что верстальщиков стараются оградить совершенно от каких-либо действий и новых знаний… Вы боитесь что работы не хватит что ли? Почему верстальщику не знать синтаксисы простейшие? Это бред полный, как по мне… Тогда зачем у программистов такая масса новых «игрушек»: всякие библиотеки новые, новые движки, новые версии софта? А что у верстальщиков? Один и тот же код — день за днем, сайт- за сайтом, через полгода активной работы, сделается 75-85% всех вариантов возможных, дальше все шаблонно… И что тогда? Как эти бедолаги крышей не сворачиваются?..

PS: мое личное мнение, что пора подталкивать верстальщиков к работе более прогрессивной… и чтобы на некоторых участках они могли заменять и программиста, для того, чтобы у более «производительного» коллеги развязаны были руки на другие вопросы. Один из вариантов лучших только — это верстальщик с знанием JS и какого-либо JS framework'a, но для таких освоить, синтаксис того-же Smarty — это час на чтение, или день на метод научного тыка.
0
ArtemS, #
Поймите, менять шаблон может не только профессиональный верстальщик, но и студент, установивший свой первый сайт или начальник какой нибудь фирмы, чтобы не тревожить программистов. Что плохого в желании помочь таким людям?

А чем от человека меньше требуется, тем ему можно меньше платить, вот и выгода.
0
janson, #
В любом случае в шаблоне появляется логика отображения при достаточной сложности системы.
Если в простейшем варианте мы имеем сложный шаблон — значит вероятно что-то не так в самой системе.

А при работе с более-менее продвинутым программным продуктом почитать мануал лишним не будет.
0
Bonch, #
Я еще не видел ни одного верстальщика, кто бы занимался натягиванием шаблона на систему. Все это всегда делают программисты — верстальщик только передает им готовые шаблоны.

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

0
zhekanax, #
Ситуация примерно схожая с яваскриптами и аяксом. Мы поступаем следующим образом — пишем что и по какому адресу взять/положить (согласовываем api) и все счастливы
А верстальщик который натягивает шаблоны на приложение, по-логике, должен существовать. Почему это программисты должны думать о том что и где отобразить.

barba.habrahabr.ru/ с удовольствием правит шаблоны symfony :) Я думаю что стоит обучать верстальщиков работе с шаблонами, освобождая программистов у которых итак хватает заморочек
0
funca, #
Верстальщики прекрасно знают что такое парадигма наследования, хотя бы из css. И не пользоваться этой мощью в шаблонах — путь в говнокод.

Проблема в том, что за словом «наследование» скрывается куча разных по смыслу понятий. В программировании, наследованием называют логическое отношение обобщения (is-A) для типов данных. В css же, под наследованием понимается механизм каскадной композиции свойств.
+2
panandy, #
Да ну. Возможно наследование и так. Но вы предлагаете все генерировать программисту в контроллере, а верстальщику только указывать места вывода переменных? А если нужно сменить хоть один символ, просить программиста?
Значит нужно искать в проект умного верстальщика, который знает что такое наследование и цикл, и переменная )))
–3
sylvio, #
Прекрасно. Вы предлагает изменять верстальщику логику работы программы по своему усмотрению.
А потом программист часами дебажит код в поисках чего же там чертподери не так.
+2
panandy, #
Нет, я просто говорю о том, что верстальщик — это не только человек который знает хтмл. Ведь внешний вид сайта — это и количество новостей в блоке, и то как такой каждый блок выглядит, разные стили дял четных и нечетных строк таблицы(знаю что такое можно и на js сделать, и на css, но в случае css не полная поддержка браузеров) — все это циклы и условия в шаблонах. Если за каждой такой проблемой верстальщик будет бегать с к программисту, хорошего с этого точно не получится. Будет проще нанять программиста-верстальщика, который сам все сделает.

Насчет поисков и дебага — нужно правильный шаблонизатор использовать, который не даст верстальщику писать чистый php.

Да и ничего страшного, если верстальщик выучит пару новых команд, html и css как то же выучил?
+2
sylvio, #
Я имел ввиду, что верстальщик должен заниматься именно представлением данных, а не обрабатывать их самих («сменить буковку»). Иначе получится, что левая рука не знает, что делает правая — какая же это командная работа тогда.
+2
Bal, #
Не все верстальщики незнакомы с программированием. Не все программисты не являются верстальщиками.
+1
zhekanax, #
Наш верстальщик с удовольствием пользуется view.yml (symfony) и регулярно спрашивает как реализовать что-нибудь в шаблоне. Так что может стоит разделять на несолько категорий:
* нарезальщик мактов
* верстальщик + клиентское программирование
* и, например, веб-технолог или веб-дизайнер (насколько я понимаю, в русском языке под этим словом понимают нечто отличное от оригинального web-designer) — тот который занимается не только непосредственно версткой, но и, по возможности, ее внедрением в приложение.
+3
egorinsk, #
Да вы упоротый, расскажите мне тогда, как можно сделать шаблоны для сайта без наследования и *без* копипаста кода (что является крайне дурной практикой), ну?

Вариант «использовать include header/sidebar/footer» — уродский, негибкий и создает кучу сложностей.

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

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

Ну значит, тогда верстальщик будет делать статические ХТМЛ-страницы, а программист — вписывать туда циклы и наследование.
–2
ArtemS, #
Сперва, ну стоит другие варианты называть уродскими, если они лично вам не нравятся.
Вариант с include более понятный, существует еще со времен SSI. Нужно заменить title в заголовке — сделайте его переменной.
НЛО прилетело и опубликовало эту надпись здесь
0
egorinsk, #
> Нужно заменить title в заголовке — сделайте его переменной.

Почему это плохо? Потому что, задать название страницы я могу, только явно указав переменную title в контроллере, а в шаблоне я название задать не могу. Вариант типа [?php $title ='lalaa'; include 'header' ?] я даже не рассматриваю из-за неуклюжести (так как это имитация вызова функции с передачей параметра).

Единственный логичный выход при использовании php тут — сделать header функцией с параметром title и вызывать через print_header($title).

А теперь представьте, ситуацию чуть сложнее: у вас есть шаблон главной, и вам надо сделать дочернюю страницу, заменив центральную часть, добавив пару блоков в правую колонку, подключить пару css-файлов в заголовке, добавить несколько ссылок в футер.

Ну? Будем резать шаблон на 10 кусков? Вводить кучу бессмысленных переменных типа $title, $right_column_bloks[], $footer_links[]. У вас есть решение для задачи, с которой сталкиваешься при разработке *любого* сайта, состоящего больше чем из одной страницы?

А завтра понадобится на всех страницах раздела новостей добавить в хедер баннер. Что? Будем добавлять переменную $is_news_template и выводить баннер через if?

Познакомьтесь уже с наследованием и потом без него обойтись не сможете :)
НЛО прилетело и опубликовало эту надпись здесь
+1
pipboy, #
Хорошая статья, читал ее еще в оригинале. Не знаю, что подвигло Фабьена на такие резкие изменения, но буквально через какое-то время он еще решил убрать обратную совместимость с PHP 5.2 во второй версии symfony. Это, несомненно, большой шаг вперед, и симфони от этого только выиграет.
–4
Lux_In_Tenebris, #
Даёшь XSLT в массы и точка. :)
–2
vvn, #
Вы что, шутите? Это, получается, дизайнеру-верстальщику надо учить XSLT, который на порядок сложнее любого шаблонного языка, а программисту в контроллере генерировать XML (исключительно для того, чтобы потом с помощью XSLT его преобразовать в HTML). Да и само преобразование — процесс не особенно быстрый. И ради чего все это?

Искренне не понимаю людей, которые пытаются продвигать XSLT в качестве замены шаблонизаторам.
+3
sylvio, #
Люди думают, что раз так делают на джаве, то это круто.
+2
Lux_In_Tenebris, #
Конкретно Java тут каким боком то? XSLT доступен для использования на множестве разноплановых платформ/сред.
НЛО прилетело и опубликовало эту надпись здесь
0
ibnteo, #
На Java он и зародился, и вторая версия XSLT там уже давно используется.
0
CAH4A, #
Так ведь XSLT 2 ещё не стандартизирован? :)
0
ibnteo, #
Ну и что с того, XSLT 1 тоже начали применять до завершения стандартизации, у MS прикольная реализация была.
0
Lux_In_Tenebris, #
большому кораблю — большую торпеду (в хорошем смысле) :)
+1
FB3, #
Еще люди думают, что раз так у Яндекса, значит это круто :)
Но вообще, XSLT в качестве шаблонизатора мне нравится…
+2
Lux_In_Tenebris, #
Да и само преобразование — процесс не особенно быстрый

Докажете?
Я лично не занимался тестами скорости XSLT, но не сказал бы, что он в среднем медленнее традиционных «шаблонизаторов», написанных на интерпретируемых языках. Удобство и универсальность так или иначе пересиливает многие возможные его недостатки.
–1
vvn, #
Я тоже тестами лично не занимался, но здравый смысл мне подсказывает, что разбирать и исполнять конструкции шаблонных языков куда проще, чем XSLT.

Скажите лучше что-нибудь по другим пунктам. Что в нем удобного-то? Он избыточно сложный и избыточно универсальный для такой задачи. Когда вам надо сделать список покупок в магазине, вы его в TeX верстаете, а потом заказываете печать в офсетной типографии?
+4
Lux_In_Tenebris, #
XSLT при генерации конечного результата использует нативные библиотеки, что уже даёт фору перед большинством шаблонизаторов, работающих на интерпретируемых языках.

Мне кажется насчёт сложности и избыточности — это всё стереотипы. Вы с ним имели дело хоть раз? Изучили парочку простейших шаблонов? Никто же не заставляет вас изучать абсолютно каждую существующую возможность XSL преобразований досконально, чтобы решать какие-то простейшие задачи. Это удобно даже для сайтов из десятка страниц, а главное — очень гибко и отлично масштабируется при первой необходимости.
–3
LastDragon, #
Работал с XSLT немного (верстка для HostCMS), по-моему главный его недостаток в том, что неудобно читать шаблоны — мешанина из тэгов (разные пространства имен не спасают).
+1
CAH4A, #
Ну, смотря как шаблон написан.

Вы в лабу по Си одногрупнику смотрели? Там тоже мешанина, и что же теперь, Си плохой?
+2
egorinsk, #
Синтаксис Си плохой, устаревший, зачастую двусмысленный, склонный к ошибкам (знаете, почему пишут if (0 == x), а не наоборот?), требующий очень много букв на то, что в других языках делается одной строчкой. Плюс там нет модулей и надо руками писать заголовочные файлы, определять функции до объявления (делать одну и ту же работу 2 раза фактически). и еще много чего. Почитайте, например у автора языка D ( www.digitalmars.com/d/2.0/overview.html ), какие недостатки он нашел в Си.
–1
CAH4A, #
Вы проблемы компилятора переложили на плечи синтаксиса. :)

А синтаксис хорошь, ведь в D си-подобный синтаксис, га?
0
egorinsk, #
В D многое изменено по сравнению с Си, потому он и хорош :) Он Си-подобный, но другой)
0
LastDragon, #
Я не говорил что XSLT плохой, преимущества у него есть и их глупо отрицать. Но вот синтаксис удобным назвать нельзя и в больших шаблонах получается действительно мешанина.

Для примера, часть реального шаблона: pastebin.org/55704

Удобно? Понятно? Мне — нет.

+1
ibnteo, #
Похоже вы его не умеете готовить, об этом говорит множество xsl:variable, использование рекурсивного вызова шаблона там где это не нужно. Подготовьте данные для пейджера в PHP, и заставьте шаблонизатор лишь вывести их.
–1
LastDragon, #
Это шаблон из бесплатной редакции HostCMS, т.е. реальный пример того с чем придется столкнуться при работе XSLT.
+2
ibnteo, #
Это лишь говорит об уровне программистов HostCMS. Вот поэтому XSLT и не прет, просто большинство программистов пытаются на нем писать императивно, а потом жалуются что ерунда получается. Замечено не раз, кстати.

Эта мания заводить побольше xsl:variable идет от привычки все держать в переменных, которых в XSLT на самом деле нет. Так же признаком неумения делать XSLT шаблоны является частое использование именованных шаблонов <xsl:template name="">

На месте программистов HostCMS я бы просто сформировал узлы
<pages><page>1</page><page>2</page><page>3</page></pages>

и потом просто бы вывел:
<template match="pages>
<xsl:for-each select="page">
<a href="{/document/forums_path}{/document/forums_id}/{theme_id}/page-{.}/">
<xsl:value-of select="."/>
</a>
</xsl:for-each>
</template>
0
LastDragon, #
Я с Вами согласен, разве что забыли добавить пометку активной страницы.

Но почему-то мне кажется, что большинство напишет как в первом примере (если приложения не только для себя это рано или поздно случится, т.к. проверять всех кто правит шаблоны не будешь). Разбираться в подобных шаблонах у меня желания нет, т.е. для себя я сделал вывод: в тех приложениях где нельзя гарантировать определенный уровень XSLT верстальщика (а они есть?) предпочтительнее обычный шаблонизатор.
НЛО прилетело и опубликовало эту надпись здесь
+5
ibnteo, #
Расскажите кому-нибудь про хороший PHP, и про ошибки, которые на нем делаются. Однако это не мешает делать на нем отличные сайты, правда для этого приходится учиться.

А XSLT, кстати, позволяет избежать множества ошибок. Даже делая тест скорости шаблонизаторов, я обнаружил ошибки HTML кода в малюсеньком PHP тесте. Всевозможные XSS дыры на сайтах появляются благодаря хорошему языку? На XSLT сайте встретить такое можно гораздо реже, т.к. архитектура языка не позволяет такие ошибки делать по-умолчанию. Хотя конечно здесь может быть просто выше порог входа.

Заметил, что если шаблон не дал ошибку сразу, то он будет работать в любых ситуациях, в отличие от других шаблонизаторов, он посчитает и деление на ноль (получится бесконечность), и не упадет при обращении к несуществующему индексу в массиве.

В том же PHP чтобы исключить полностью SQL-инъекции, достаточно просто применять PDO для работы с базами данных. Но, насколько могу судить по исходным кодам разных проектов, эта библиотека применяется крайне редко. Парадокс.
НЛО прилетело и опубликовало эту надпись здесь
+6
ibnteo, #
Отвечу коротко, на легкоизучаемых технологиях делают ерунду, чтобы сделать стоящее, надо сначала хорошо изучать предмет, PHP как пример.
PHP говнокод = XSLT говнокод
PHP нормалкод = XSLT нормалкод

В общем изучайте Ruby, и не парьтесь.
0
FB3, #
В том же PHP чтобы исключить полностью SQL-инъекции, достаточно просто применять PDO для работы с базами данных. Но, насколько могу судить по исходным кодам разных проектов, эта библиотека применяется крайне редко. Парадокс.

Достаточно mysqli, PDO — больше на объектах завязано. Хотя принципиально разницы нет конечно.
+2
CAH4A, #
В XSLT одно и тоже преобразование можно написать десятком путей. Поэтому мы можем говорить и о архитектуре шаблона.

И новичёк, не имея хороших примеров перед собой, соответсвенно, совершает архитектурные ошибки. И выглядит это уродски. А совершает он их по простой причине того, что думает, что всё программирование императивно.

Должен ли быть сделан язык шаблонизатора так, чтобы исключить архитектурные ошибки новичков? Я считаю, не должен.
0
FB3, #
habrahabr.ru/blogs/xslt/47545/
В конце мой шаблон, предназначенный для того же, что и у вас по ссылке. По моему вполне читабельно получилось…
+2
Lux_In_Tenebris, #
перенастройте подсветку синтаксиса :)
впрочем, я и без оной не испытываю неудобств с XSL, главное — привыкнуть
+3
vvn, #
Ну давайте сравним на простейшем примере, никаких стереотипов:

Нормальный шаблонизатор:
{% for item in items %}
* {{ item }}
{% endfor %}

XSLT:
<xsl:template match=«items»>
<xsl:apply-templates/>
</xsl:template>

<xsl:template match=«item»>
* <xsl:apply-templates/>
</xsl:template>

Мало того, что символов втрое больше, так это и выглядит совершенно нечитаемо для верстальщика. И это самая простейшая задача. Что в этом удобного? Ну или я не знаю, я не специалист по XSLT, может быть это проще сделать можно?

И еще такой вопрос: в цепочке «данные -> XML -> HTML» для чего нужен XML? Только для того, чтобы можно было воспользоваться XSLT? Все это, повторюсь, попахивает несоответствием инструмента задаче.

Я не говорю, что XSLT — какой-то сверхнепонятный язык, который кто-то не в состоянии постичь; в любой технологии можно разобраться, затратив на это определенное время, и после этого она перестанет казаться непонятной. Суть моих претензий, во-первых, в несоразмерности задачи и усилий, затрачиваемых на знакомство с технологией, во-вторых, в синтаксической и семантической избыточности XSLT при использовании в шаблонах сайтов, а в-третьих, в несоответствии технологии задаче (зачем мне XSLT, если у меня нет XML, а есть реляционная БД?)
+3
DmitryKoterov, #
Хочу заметить, что длинно или коротко — не всегда важно, все зависит от качества подсветки и автодополнения кода в редакторе. (Хотя, конечно, идеального редактора для XSLT-шаблонов я пока не видел; ближайший кандидат для меня — XML Spy для Eclipse, но он платный.)

Кстати, for не эквивалентен xsl:template. Лучше уж сравнивать for и xsl:for-each. Лично моя практика показывает, что xsl:template в основном используется для определения именованных блоков, подверженных наследованию, т.е. для того же, что есть в Джанге. А с использованием ShortXSLT for-each и вовсе записывается вот так:

{for-each /nodes/*}
Name: {./name}
{/for-each}
0
vvn, #
Я просто понять не могу, зачем нужны все эти сложности с генерированием промежуточного XML, использованием надстроек-компиляторов для XSLT, изучением не самого простого языка, если есть простой и удобный способ. Да, есть весьма ограниченный круг задач, когда этот самый промежуточный XML может еще где-то пригодиться, но в большинстве случаев он никому не нужен.
+2
DmitryKoterov, #
Эх… дался Вам этот промежуточный XML. :-) И потом, почему ИМЕННО ЭТОТ промежуточный слой вызывает столько вопросов? Чтобы его закодировать, нужно всего-то 30 строк кода. А ведь есть еще другие, более грандиозные, слои: это сам интерпретатор PHP, парсер PHP во внутреннее представление, написанный на Yacc + Bison (или Lex, не помню точно), который компилируется программу на Си, которая обрабатывается препроцессором cc, который подается на вход gcc, из которого gcc делает внутреннее платформенно-независимое представление, которое превращается в объектный файл, который отдается на вход линковщику, который запускается в отдельном адресном пространстве, выделенном ОС, которая написана на Си, который написан на более старом Си, который написан на еще более старом Си, который ..., который написан на ассемблере, который написан на более старом ассемблере, который ..., который написан в машинных кодах. (Уверен, что я еще потерял по дороге добрую сотню промежуточных слоев, ну да ладно.)
+3
ArtemS, #
Эти слои абстракты и мы никак не может на них повлиять, если только не сделать форк, либо выбрать другой язык. XML более чем реален и от него еще более реально можно отказаться (в шаблонах).
+1
egorinsk, #
Блин, PHP-шаблонизаторы генерируют PHP-код, который исполняется, может быть закеширован опкешером, а XSLT — это обработка, парсинг 2 (!) XML-файлов, сложные преобразования, и кешировать тут просто нечего (разве что можно шаблон преобразовать в дерево и сохранить сериализованную версию, но все равно эт намного менее оптимально).

И писать в контроллере $this->set(array('a' => 6, 'b' => 7)) куда как проще, чем добавлять вызовы для генерации Xml (еще лишние тормоза).

И да, читать XML человеку практически невозможно, ни с какой подсветкой, так как слишком многог букв и лишних значков. Ну и набирать дольше, а про IDE — это вообще смешно, получается я без тяжелой тормозной иды не могу теперь файл нормально редактирвоать? Извольте, сударь, я как-нибудь без этого обойдусь)
+1
ibnteo, #
PHP код точно так же обрабатывается интерпретатором, как и из текстового XML собирается DOM в памяти. Нужно просто знать, что DOM это накладно по памяти, и не подсовывать гигантские XML файлы.

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

Для формирования XML используйте SimpleXml, из PHP данные выглядят как обычный объект, можно использовать XPath для хождения по дереву, и в конце выгрузить XML в DOM и произвести XSLT трансформацию (получается быстрее чем формировать сразу DOM).

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

Если не можете читать XML, то как же вы читаете HTML? Шаблоны XSLT это не самые большие файлы проекта, набирать их не сложно, дело лишь в привычке. Если же хотите сэкономить для своих пальцев пару килобайт кода, то воспользуйтесь какой-нибудь компилирующей библиотекой для XML/XSLT. Не могу посоветовать какой именно, т.к. ни одну не использовал в деле за ненадобностью.
–1
vvn, #
Вы сейчас человеку, который не хочет съесть не кактус, а пирожок, советуете как все-таки лучше съесть кактус. Мол, нужно выбирать кактусы с иголками помягче, приглаживать их к поверхности перед едой, и еще можно немного в микроволновке подогреть. Тогда совершенно ничего страшного в этом и не будет. Но вопрос-то при этом никуда не девается — зачем глотать кактус, когда есть пирожок?
+4
ibnteo, #
Ну для кого это и кактус, а для кого и пирожок. Я вот использую XSLT уже очень с давних пор, когда его в PHP еще и не было. Другие шаблонизаторы смотрел, но не находил удобного для себя, все они слишком перегружены функциями, и не умеют нормально работать с деревьями.

И если человек не зная XSLT утверждает что он кривой, то он явно не прав. Понятно что его научить с таким подходом невозможно, но пускай других не вводит в заблуждение. Раз сам не осилил, то это не значит что не осилят другие.
0
vvn, #
Не надо меня выставлять идиотом, я в состоянии осилить XSLT, несколько лет назад писал несколько шаблонов и вполне представляю, что это такое. Я не говорю, что он кривой; я полностью согласен с тем, что XSLT — мощный и универсальный инструмент. Но это не повод применять его везде.

Вы бы еще предложили писать сайты на Хаскелле, он же тоже функциональный, и вообще такой изящный и абстрактный.
0
ibnteo, #
Я про вас лично ничего не говорил. Да и о чем вообще спор, раз архитектурно не подходит какая то технология для проекта, то и не нужно ее пихать.

А на хаскеле вполне люди создают сайты, я пока не осилил в достаточной мере этот язык. Надо будет на досуге продолжить изучать.
0
egorinsk, #
> Для формирования XML используйте SimpleXml, из PHP данные выглядят как обычный объект, можно использовать XPath для хождения по дереву, и в конце выгрузить XML в DOM и произвести XSLT трансформацию (получается быстрее чем формировать сразу DOM).

Все эти лишние раширения только прибавляют тормозов. Добавить элемент в массив или извлечь оттуда куда как быстрее и не требует никаких расширений.

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

Но все же там, где я сталкивался, такая универсальность была излишней. Потому использовать php-шаблонизаторы (для меня) проще и удобнее.
+2
ibnteo, #
Меня впечатляет не только универсальность и распространенность на всех платформах, но и удобство работы с деревьями, оси навигации. Насчет тормозов, я сейчас делаю форумный движок со сложным выводом древовидных комментариев, в нем используется XSLT, так он быстрее в 2 раза чем phpbb3, в котором примитивные плоские комментарии, и очередной нестандартный шаблонизатор.

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

Любой из предлагаемых шаблонизаторов будет по объему кода больше чем мой проект в несколько раз, поэтому использовать их смысла нет, ведь XSLT уже встроен в PHP, и, в отличие от этих шаблонизаторов, не содержит ошибок.
–1
egorinsk, #
> так он быстрее в 2 раза чем phpbb3

Вы бы еще написали «быстрее чем Друпал». Сравнивать с кое-как на коленке написанным решением нечестно. Тем более, что phpbb — старый проект, со всеми вытекающими.

Так что, насчет универсальности и древовидных структур я спорить не буду, а вот в то, что XSLT быстрее, не поверю :(

+1
ibnteo, #
Он не везде быстрее, вот для обработки деревьев лучше нет, и быстрее программировать, и работает очень шустро. Я тестировал скорость XSLT по сравнению с нативным PHP и Smarty, XSLT оказался ближе к PHP, и довольно ощутимо опередил Smarty. Пример с phpbb привел, так как только что вышла новая версия, ведь этот движок считается не медленным. После сравню с другими движками, более быстрыми и современными.
–2
egorinsk, #
Почему тормозит смарти — я понял, очевидно, из-за того, что там инклюдится довольно-таки большой Smarty.class.php, и генерируется довольно-таки неуклюжий шаблон, а вот почему XSLT ненамного медленнее php — понять не могу, это как-то странно ((

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

Надеюсь, в новых версиях php исправят баги с производителностью, и ваш XSLT займет заслуженное последнее место :)
0
seriyPS, #
Этот XML кешировать клево))
+2
ibnteo, #
Используйте SimpleXml, с ним и удобно работать, и удобно из него данные брать в самом PHP. Плюс еще есть возможность использовать XPath. Оси навигации в XPath это очень классная штука. Да и функциональный принцип программирования, что в XSLT, для шаблонов лучше подходит. Ну и то что XSLT есть на всех платформах, добавляет такой жирный плюс, каким ни один из существующих шаблонизаторов не сможет похвастаться.

Купите нормальную книгу, постарайтесь разобраться как правильно писать шаблоны на XSLT, вот тогда он понравится очень сильно.
0
egorinsk, #
Вот мой комментарий, habrahabr.ru/blogs/php/75901/?reply_to=2203909#comment_2203960

Вы можете предложить какие-то техники по ускорению XSLT? По повышению удобства работы с нечитаемыми XML-шаблонами?
+1
ibnteo, #
Ответил там по тому комментарию.

Ускорение какого рода имеете ввиду, разработки, выполнения?

По поводу удобства, похоже что это дело привычки, я вот не могу читать PHP нативный шаблон (<?php code ?> и <?= env ?>), да и всякие другие нестандартные виды шаблонов, просто не работал с ними.
0
egorinsk, #
Для меня, конечно важно ускорение разработки (за счет удобного синтаксиса), но скорость выполнения все же важнее :)

По поводу синтаксиса, вот пример (угловые скобки я заменил на квадратные, позор парсеру хабра):

[a href=«articles/{$article.id|escape:url}.html»]ссылка[/a]

(Модификатор escape:url экранирует не-буквенно-цифоровые символы в названии статьи, заменяя их на знак процента с hex=кодом символа). Разве это сложно? Разве на Xml это будет проще, а?

Поверьте, Xml освоить куда как сложнее того же Twig, Smarty или dwoo :)
0
vvn, #
Ну вот, докатились, только для того, чтобы написать правильный шаблон, уже нужно покупать книгу.
+2
ibnteo, #
Ну не используйте тогда XSLT, кто же заставляет то? И CSS не используйте, его же тоже нужно изучать.
0
vvn, #
Ну как же, адепты XSLT в этой ветке уверяют, что XSLT — это лучшее решения для шаблонов в проектах любого масштаба. Просто объясните, зачем усложнять вещи, которые МОГУТ быть простыми? KISS ведь и все такое.

C CSS сравнение некорректно, потому что альтернатива CSS — это кашеобразный HTML с атрибутами и без возможности повторно использовать стили, а альтернатива XSLT в контексте нашего разговора — простые и читаемые шаблоны. И не надо сравнивать сложность CSS и XSLT.
+2
ibnteo, #
Вполне корректное сравнение, оба этих языка (CSS и XSLT) декларативные. А предлагаемые шаблоны используются лишь на одной платформе (PHP), и не настолько они и читаемы (например для меня), это лишь дело привычки. Если бы все было просто, то не выдумывали бы шаблоны вообще, пользовались бы нативным PHP, но нет же, развелось их целый воз и маленькая тележка.

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

Сравниваю еще с CSS, т.к. он посложнее будет чем XSLT, но его все равно придется изучать. И никто не пытается впаривать всем свой заменитель, основанный на JS, например.
0
vvn, #
Корректность сравнения зависит от контекста сравнения и особенностей сравниваемых сущностей в этом контексте, а не от того, что оба языка декларативные. Я вам объяснил, что у CSS нет альтернатив, а у XSLT — есть.

Предлагается не какой-то конкретный шаблонизатор, а подход. Этот подход имеет свои реализации на любой веб-платформе — PHP, Python(Django/Pylons), RoR. Они все настолько простые, что для того, чтобы в них разобраться, нужно минут 10 (на прочтение 1 страницы с документацией).
0
FB3, #
Из редакторов XML (в т.ч. XSLT) мне всегда очень нравился Stylus Studio, но он тоже платный…
+2
regeda, #
Конечно же, реляционные БД можно быстро отображать с помощью Пыха напрямую, но XSLT дает универсальную возможность преобразования структурированных данных в любую последовательность отображаемых данных. И в связке Data -> XML -> HTML могут появится при абстрактных задачах связки вида: Data -> XML -> Data, HTML -> XML -> Data, XML->XML->Data, XML -> XML -> HTML и тд и тп.
Все зависит от Ваших задач. Скорость или универсальность? Выбирать Вам!
0
vvn, #
Я и не спорю, что есть задачи, когда XSLT — подходящий инструмент. Например, выдача Яндекса, которая может показываться на самом Яндексе, а может отдаваться через Яндекс.XML. В таких случаях это действительно оправдано. Но когда речь идет о не очень больших сайтах, для которых нету необходимости все выходные данные предоставлять в нескольких форматах, я не вижу ни одной причины для использования XSLT. А таких сайтов в Интернете, наверное, 95%.

И только тот факт, что XSLT универсален и стандартизован, не делает его лучшим решением во всех случаях.
+2
regeda, #
Любое решение, которое стандартизовано уже должно вызывать сомнение по поводу того — «а не является ли это решение универсальным»…
0
VolCh, #
И не является ли оно, в силу своей универсальности, избыточным для данной задачи… ;)
0
Lux_In_Tenebris, #
Если вы приобрели набор слесарного инструмента, непременно нужно зайдествовать каждый его вид? Или всё же по мере необходимости?
0
VolCh, #
Задействовать-то по необходимости, а вот таскать, как правило, придётся весь ;)
–2
regeda, #
Эти 95% просто не знали о существовании XSLT
+1
vvn, #
Речь не о том, знали они или нет, а о том, что им не нужны все те преимущества, которые дает XSLT.
0
regeda, #
Если XSLT не дает им преимущства, то тогда «о чем речь»?
0
vvn, #
Речь, собственно, о «Даёшь XSLT в массы и точка.». Конкретно у нас с вами, видимо, особых разногласий и нету :)
0
regeda, #
Я не холивар! Если «XSLT давать в массы», то «точка» здесь ни при чем…
0
egorinsk, #
Мне например, удобнее всего передавать данные в виде одного большого PHP-массива, и такой способ никак не мешает добавлять дополнительные преобразования, но лишен недостатков в виде тормознутости и нечитаемости XML.
+1
Lux_In_Tenebris, #
зачем мне XSLT, если у меня нет XML, а есть реляционная БД

Как будто вы в случае с традиционными шаблонизаторами сразу имеете возможность отправить результат произвольного SQL запроса в шаблон. Если даже где-то такое и предусмотрено — тут попахивает всевозможными косяками.
Сделать автогенерацию XML дерева на основе результата запроса — пара пустяков. Более того, с таким универсальным решением задачу по минимальному преобразованию и отрисовке результатов можно переложить целиком на XSL шаблон.

Приведённый вами пример или испорчен парсером Хабра, или вы не имеете даже базового представления об XSL.
–1
VolCh, #
>Сделать автогенерацию XML дерева на основе результата запроса — пара пустяков.

Помню первый свое XML дерево построил на базе SMARTY :)

>Более того, с таким универсальным решением задачу по минимальному преобразованию и отрисовке результатов можно переложить целиком на XSLT шаблон.

После этого только один браузер из тестирируемых заставил отобразить связку XML+XSLT (сейчас, наверное, дела получше, но ИЕ6 еще есть).

>или вы не имеете даже базового представления об XSL.

Могу прикинуть, что базовое представление такое же как у меня — то есть изучал когда-то давно из интереса к новым технологиям по статье в каком-нибудь журнале и по справке встроенной в DreamWeaver
0
ibnteo, #
Уже давно некоторые браузеры научились обрабатывать XSLT, но до сих пор это не применяется на практике из-за недостаточной поддержки всеми современными браузерами.

Поэтому XSLT применяется на сервере, после трансформации данные отдаются браузеру в HTML или XHTML виде, и тут уж любой браузер отображает их нормально.
0
vvn, #
Вовсе не обязательно непосредственный результат из SQL запроса отправлять в шаблон. Суть в том, что мои исходные данные не представлены в XML, и чтобы воспользоваться XSLT, мне надо искусственно генерировать XML, который мне больше не нужен ни для каких целей. При этом я еще и теряю возможность передавать в шаблон объекты. Вот вам другой пример:

{% for comment in post.comments %}
{{ comment.short_text }}
{% endfor %}

Чтобы это реализовать на XSLT, мне сначала придется сгенерировать руками XML (никакой рекурсивный обход массивов или автогенерация мне не поможет, потому что short_text — это метод), а потом еще и XSLT-шаблон написать. И зачем это нужно? Никто еще не привел ни одного убедительного плюса XSLT, кроме того, что промежуточный XML можно еще куда-нибудь приткнуть.
0
k4d, #
посмотрите выставку cebit2009, какие проекты там представлены и в каких используется XSLT!
XSLT является стандартом по дефалту в .NET…

Если вы не в состоянии понять плюсы использования XSLT — не используйте его, вопрос лишь в том, что будете ездить на квадратных колесах с горе шаблонитизаторами на PHP
0
vvn, #
Ох, уели вы меня, уели, не знаю даже, что и возразить… Cebit2009 это очень круто, я сдаюсь, конечно. Поеду скорее отсюда на своих квадратных шаблонитизаторах.

А если серьезно, то можете по существу что-нибудь возразить, а не гнуть пальцы?
–2
k4d, #
XSLT промышленный стандарт! XSLT используется для гораздо более сложных проектов чем сайты на PHP… Про мелкие задачи — грех обсуждать…

а скриптовые шаблонитизаторы для PHP — отход от принципов веба — тэги!
+3
ibnteo, #
Я тестировал скорость XSLT относительно простого PHP и Smarty, оказался довольно шустрым, особенно если использовать SimpleXml для подготовки данных.

А то толкают уже давно миф что XSLT медленный, видимо выгружали всю базу в XML, и хотели чего-то выдающегося увидеть.
+7
regeda, #
XSLT — универсальный паттерн, описывающий шаблонизатор. Во-первых, он универсален, во-вторых, он страндартизован, в-третьих, на вход поступают структурированные данные. Что еще надо?
+4
DmitryKoterov, #
По поводу XSLT, XML и сокращенных тэгов.

1. Не нужно, конечно же, генерировать XML в контроллерах, откуда эта фантазия? В контроллерах можно генерировать нативный PHP-массив, который несложной рекурсивной функцией автоматически преобразуется в XML, а тот уже подается на вход XSLT. В итоге, хоть XML и есть, но нигде в коде он явно не генерируется. А отлаживать шаблоны и предоставлять внешние API удобно.

2. С многословностью XSLT лично я борюсь вот так: dklab.ru/lib/Dklab_ShortXSLT/ — это надстройка-компилятор над XSLT, которая компилирует шаблоны в XSLT. Важно, что компиляция происходит «на лету» и с кэшированием получившихся xslt-файлов, поэтому это не дает накладных расходов (своеобразный «JIT в XSLT»). Также никто не запрещает из XSLT вызывать специальные PHP-хелперы (например, для обращения к роутеру).

3. Искренне не понимаю людей, которые пишут <?php echo $a?> вместо <?=$a?>. На хостинге отключены короткие тэги? Ну так включите их в .htaccess или же воспользуйтесь функцией ini_set(«short_open_tag», true) во фронт-контроллере. Не можете написать <?xml ...?>? Ну так напишите <?='<?xml version="..."?>'?>, неужели так много мест, где это потребуется написать? Применяете PHP-вставки в XML-документах? А я предпочитаю XML-документы генерировать программно, а также с помощью XSLT.

Да, еще одно. В Смарти давным-давно имеется режим автоквотинга, только он по умолчанию выключен. (Я сам Смарти не очень люблю.)
–2
ArtemS, #
2. Речь идет о шаблонах. Чем использование вашего ShortXSLT принципиально лучше нативного php? Зачем сперва строить xml, а потом тратить время на его преобразование? Где профит???
+1
seriyPS, #
Профит в том, что этот XML можно вывести в чистом виде для "'экспресс-дебага" или предоставления примитивного API, можно одним шаблоном преобразовать в HTML, другим в XHTML, третьим — в RSS, четвертым в ATOM, пятым в PDF, шестым в SVG ))) Можно и в JSON, мне пока не приходилось…

Отмечу особо, что можно вывести в чистом XML без шаблона… Это на самом деле ОЧЕНЬ удобно когда перед тобой все входные данные безо всяких var_dump и пр. костылей
+1
seriyPS, #
Плюс этот XML удобно кешировать (причем по-кусочкам)
0
egorinsk, #
Почему php-массив с данными лучше XML-файла? Он хранится в бинарном виде, его не надо парсить, в нем быстрее ищутся элементы.

> Профит в том, что этот XML можно вывести в чистом виде для "'экспресс-дебага"

echo $xml_data, var_dump($array) — занимает ожинаково места, но 2й вариант в разы читабельнее (у меня рсширение Xdebug раскрашивает вывод var_dump())

> или предоставления примитивного API

echo Array2XML($array) — это сложно?

> можно одним шаблоном преобразовать в HTML, другим в XHTML, третьим — в RSS, четвертым в ATOM, пятым в PDF, шестым в SVG

А php-массив можно еще и в JSON преобразовать одной функцией (json_encode() вроде), а XML? А в указанные вами форматы можно преобразовать массив и обычнм шаблонизатором, и работать будет быстрей.

> Плюс этот XML удобно кешировать (причем по-кусочкам)

Мда, скажу по секрету, элементы массива сериализовать в кеш тоже недолго)

На стороне XML — всякие гиганты, типа Sun с явой и майкрософт. но мне, как человеку пишущему код. в этом мусоре копаться неохота и пальцы отбивать, наюирая тонну скобок и лишних слов. А так как на с Sun, ни с МС я не связан. то и следовать их дурацким стандартам я не буду ))

Кстати, XML достал и других разработчиков, например в symfony используется YAML, в отличие от XML он легко читается и пишется человеком (а не роботами из отдела раpработки майкрософт, которые проталкивают свой XML).

0
CAH4A, #
YML в отличае от XML не eXtensible. ))
0
seriyPS, #
Кстати, XSL очень люблю, но пока были основные проблемы в удобном интерфейсе для преобразования php переменных в XML… DOM слишком навороченный… Делать нативный PHP массив преобразуемый рекурсивно — начинаешь путаться в массиве в этом… Возникает желание для манипулирования им сделать интерфейс какой-то — снова приходишь к подобию DOM.
Какой тут подход наиболее разумный посоветуете??
+2
ibnteo, #
SimpleXml, очень удобное средство, и что удивительно, быстрее чем формирование DOM сразу.
+3
ibnteo, #
1. Можно совместить полезное с приятным, и формировать данные через SimpleXml.

2. Хелперы можно и напрямую из XSLT использовать, через php:function()
0
egorinsk, #
1) Лишние, неискоренямые тормоза получаются. Имеем: данные зачем-то преобразуются в Xml, который потом все равно еще раз преобразется.

Кстати, дерево DOM (с кучей тегов, аттрибутов, ссылок на родительские/ соседние элементы) тяжелее простого php-массива, и даже в бинарном расширении будет работать медленно, так ведь? А поиск элемента по индексу всяко быстрее поиска по Xpath (который может содержать сложные выражения к слову), эти тормоза невозмлжно оптимизировать никак.

2) Ну вот, давайте еще 30 слоев добавим. Почему бы сразу в php-код не компилировать?

3) Короткие теги — плохо, не помню почему :) Конструкция не содержит эскейпинга html entities — а значит, никуда не годится.

Удобнее всего Смарти-подобный синтаксис, с тегами, модификаторами (как у вас с этим в XML ?))) и наследованием.

Кстати, еще есть проблема локализации шаблонов.

> Я сам Смарти не очень люблю.

А я не люблю все существующие шаблонизаторы, у них у всех недостатки ((

+1
seriyPS, #
о! Хорошо что про локализацию шаблонов напомнили!
В XSLT это делается вообще шоколадно!
<xsl:variable name=«transl» select=«document( concat('translations/',$lang_,'.xml') )» />
Т.е. для разных языков создаются разные файлы $lang_.xml (см www.starcraft2.com/strings/ru_ru/strings.xml ) и непосредственно в XSL автоматически подключается нужный в зависимости от входных данных. Потом для вывода текста делаем
<xsl:value-of select="$trans/str[@id='something']"/> (см www.starcraft2.com/layout/frontpage.xsl )

Кстати, по поводу XSLT на клиенте тоже на сайте старкрафта www.starcraft2.com/ поглядите исходные коды страницы — он в зависимости от юзерагента выдает либо XSL-ки и XML либо преобразованный на сервере HTML если браузер XSL не понимает
+1
vvn, #
Шоколадно?
То же самое, например, в Django выглядит так:
{% trans "something" %}
0
seriyPS, #
Да хоспади, что все к длине записи привязываются?
Мне лично достаточно в Eclipse набрать <xsl:v щелкнуть стрелку вниз и энтер…
Подключение файла переводов <xsl:variable name=«transl» select=«document(блабла добавляется один единственный раз в заголовок корневого шаблона как правило))
0
kmike, #
Привязываются, т.к. это важно. Для скорости и удобства чтения.
0
egorinsk, #
О! Наконец-то мне дали пример XSLT-шаблона! По моему, в нормальном шаблонизаторе как минимум будет меньше букв:

> param=«concat($loc/strs/str[@id='sc2.mediahost'],'/flash/global/')»

В нормальном шаблонизаторе: param="{$varname.sc2.mediahost}/flash/global"

> xsl:value-of select="$loc/strs/str[@id='sc2.featured.link.1']"/

{$varname.sc2.feutured.link[1]|escape:html}

Ну разве не проще? А ведь оно еще и работать быстрее будет (найти элемент в масиве проще, чем в DOM-дереве по XPath).

Перевод мог бы выглядеть примерно так (мог бы, потому что я еще не написал свой шаблонизатор :) ):

{_ «Phrase in English» }

А строки берутся из файла .po (созданного с помощью gettext()). Использование gettext лучше имхо тем, что он быстрее (так как там спец. бинарный формат с массивом key => value для поиска перевода, кроме того, файл переводов при использовании Апача и PHP кешируется в памяти, и его не надо каждый раз грузить с диска), кроме того для редактирования файлов переводов есть свободное ПО с GUI (например, POEdit), а у вас надо ручками править XML ((

+1
DmitryKoterov, #
> Конструкция не содержит эскейпинга html entities — а значит, никуда не годится
Кажется, имеет место недопонимание. В XSLT по умолчанию как раз включен квотинг — просто по определению (в том и сила). А чтобы его выключить при каком-то единичном выводе, нужно писать длинное <xsl:value-of select=«val» disable-output-escaping=«yes» />. Конструкция же {val} вне тэгов в ShortXSLT просто заменяется на <xsl:value-of select=«val» />, который как раз КВОТИТ данные.
0
egorinsk, #
Ок, тут я ошибся. Когда напишу свой php-шаблонизатор, тоже сделаю автоквотинг :) И все же эти «xsl:value-of select=» — длинновато, ну не для человека этот формат, что бы там не говорили.
0
DmitryKoterov, #
Вот именно поэтому я и предпочитаю сокращать <xsl:value-of select=«val» /> до {val} у себя.
0
FB3, #
Добавлю, что квотинг нельзя отключить в атрибутах. А то это не всегда очевидно для начинающих…
0
CAH4A, #
<xsl:template match="@*">
 <xsl:value-of select="." disable-output-escaping=«yes»/>
</xsl:template>

А так разве не работает? :)
0
FB3, #
А попробовать? :)
Нет, не работает.
0
CAH4A, #
<xsl:value-of select="@title" disable-output-escaping=«yes»/>

<xsl:attribute name=«superattribute»>
<xsl:value-of select="@title" disable-output-escaping=«yes»/>
</xsl:attribute>

Первое работает так как ожидалось, второе — нет :) Вы правы.
–2
NetRat, #
Давайте не будем начинать срач по поводу XSLT, этой теме посвящено и так уже слишком много.
0
Kodeks, #
Нафиг нафиг, посидел тут с поделием explay, больше жедания нет
+1
Lux_In_Tenebris, #
В Explay это реализовано из ряда вон плохо, впрочем как и весь Explay.
Интересно, от чего же противники XSLT в данном треде приводят сплошь _неудачные_ примеры внедрения. Так легче оправдать невостребованность/неудобность данной технологии? ;)
–3
RxB, #
А я за PHPTemplate, который в Drupal'е активно юзается
–1
hazg, #
вначале было слово… угу. на том и остановимся. кесарю — кесарево. не грузите людей (которые рисуют, гуят, и развивают свое воображение) наследованием, виртуальными функциями, и )))))))

Для них должен быть ИНСТРУМЕНТ. Но язык, на котором программер пишет, имеет к этому языку весьма посредственное отношение. Восприятие другое, хоть об стенку убейся.

Суммари: пока инструмента нет, будут шаблоны.
+1
egorinsk, #
Инструмент давно есть, называется Adobe photoshop. В нем нет ни наследования, ни виртуальных функций.
0
TravisBickle, #
Впишите в сравнение Quicky и возрадуйтесь ;-)
0
kosenka, #
Quicky очень нравится. Пользуюсь им постоянно, но сейчас в процессе изучения Yii и честно скажу смотрю не в его сторону (не сторону Quicky).
0
nayjest, #
Он чем-то лучше? Расскажите. Не могу определиться с шаблонизатором в новом проекте, пока отказался от Smarty, использую свой двадцатистрочный велосипед.
+1
TravisBickle, #
Во-первых, он просто очень развит, и писался не от балды, а в применении в реальным проектам. То есть функционал по мере необходимости дописывался. Например, там есть области видимости переменных, т.е. можно объявить {local $i = 0} и эта переменная будет доступна лишь в этом шаблоне, и не перепишет другие. Есть наследование шаблонов, inline-includes, и т.д. и т.п. Сложнее сказать чего там нет.
Во-вторых, он писался под HighLoad и там сделан акцент в первую очередь на производительность. Области видимости там не копируются, плагины линкуются статично, и т.д. и т.п.

Почитайте документацию, посмотрите примеры, сами всё поймете :-)
0
nayjest, #
Ок, спасибо, посмотрю )
0
nayjest, #
Ну ок, а можно прямо из коробки сделать что-то типа такого:
1) В шаблонизатор передается ссылка на объект $page,
2) В шаблоне встречается {$page.title|deferred}
3) А где-то ниже {action news/view/18}, вызывающее функцию, которая помимо вывода в шаблон, меняет значение глобальной переменной $page, которую мы предварительно передали по ссылке шаблонизатору, в результате чего в инструкции {$page.title|deferred}, которая выше по коду мы получим вывод уже измененной переменной.

?

Я конечно вижу то там постфильтры есть, которыми это можно реализовать и т. п., но вопрос в силе (приведенный мной синтаксис взят из головы, как это будет описано в шаблоне — не играет большого значения).
Я же так понимаю, Вы — разработчик этого шаблонизатора, значит много времени этот вопрос у вас не отнимет :)

0
TravisBickle, #
Неа, из коробки такого сделать нельзя. Можно конечно написать плагинчик deferred, который будет подставлять уникальную строку в output buffer, а потом искать и подменять в нужный момент. IMHO, это положит хрен на производительность. Не вижу оптимальных путей реализации для данного костыля.

Да, Мы разработчик.
0
zhekanax, #
А где у него документация?
0
TravisBickle, #
В репе на гугле есть папке _doc.
0
zhekanax, #
Давайте сравним его в контексте перевода:
1. Наследование?
2. Песочница?
3. Автоматическое экранирование?
4. Синтаксис у него вроде вполне стандартны

Если я правильно увидел беглым взглядом то первые три пункта отсутствуют. Из чего вывод — сравнивая таким образом твиг не победишь :)
+1
TravisBickle, #
1. {extends} замечательно работает.
2. Что это? В плане защиты чего бы то ни было — это не нужно. В плане отделения областей видимости — это и так реализовано, достаточно запретить шаблону смотреть в global. Это легко.
3. Делаете auto_escape = true, и затем чтоб вывести html как есть надо сделать {$var|html}, иначе проэкранируется.
4. Более чем стандартный, расширенный синтаксис Quicky.

=) Как их можно сравнивать? В Quicky значительно больше фич, например shortcut'ы есть и компиляционные операторы. То есть можно программировать компиляцию шаблона (_if, _foreach, и т.д.).
0
zhekanax, #
Передам Фабиену если он ответит в твиттер :)
0
TravisBickle, #
Описка: 4.… расширенный синтаксис Smarty Quicky.
0
TravisBickle, #
А, я еще забыл указать что в Quicky можно объявлять функции в шаблонах =) И делать рекурсивный вывод чего-нибудь таким образом =)
+1
Goodkat, #
А чем ему <?= не угодил?
0
ArtemS, #
В случае когда короткие теги включены PHP будет интерпретировать xml вставки как свой код.
0
vladsm, #
Что делают xml-вставки в PHP-коде?
+2
ArtemS, #
Наоборот, php код в xml файле. Вообще за конструкцией <? может идти все что угодно, xml, php да мало ли что еще придумают в будущем. И обработка коротких тегов добавляет только проблемы.
+1
vladsm, #
Т.е. сознательный отказ от возможностей самого языка ради очередной прослойки, синтаксис которой снова должен учить верстак.
Я ещё понимаю, когда речь идёт про C-шные шаблонные движки для php. Но php на php для php?
–1
ArtemS, #
Отказ от <? в пользу <?php. Уже сейчас вы не можете вставить в шаблон xhtml строку
<?xml version=«1.0» encoding=«UTF-8» ?> предусмотренный стандартом.
Если у вас сейчас нет проблем с короткими тегами в шаблонах, вы не застрахованы что они у вас не появятся через год или два.
+5
vladsm, #
Я правильно понимаю, что в одном месте написать <?='<?'?>xml — действительно сложнее, чем всюду по коду писать <?php echo вместо <?=?

Если у вас сейчас нет проблем с короткими тегами в шаблонах, вы не застрахованы что они у вас не появятся через год или два

Чертовски верный аргумент. На уровне «Если вы живы в данный момент, то это ещё не означает, что через год или два так же будете живы».
0
zhekanax, #
<?='<?'?>xml

Ну это ведь чертовски некрасивый костыль
0
vladsm, #
Ну так любители echo и тут не остались обделёнными — они имеют возможность написать <? echo '<?xml version=«1.0» encoding=«UTF-8»?>'?>
А теперь ещё задумаемся о том, что значение кодировки будет являться точно таким же динамическим параметром, например.
То есть весь сыр-бор из-за вывода '?', причём наверняка это ещё и окажется всего в одном месте в каком-нить одном общем подключаемом шаблоне заголовка…
0
zhekanax, #
Давайте остановимся на том что у нас разная религия? :)
+2
vladsm, #
А как же крестовые походы и убиение неверных?!?
–1
zhekanax, #
Да с удовольствием.
*Полез читать википедию т.к. в школе не читал историю*
Кресто́вые похо́ды — серия военных походов, направленных против «неверных».

Осталось решить кто «неверный»
+2
ArtemS, #
Я знаю что я не буду иметь проблем, если буду использовать "<?php". Это придает чуточку уверенности. Я это принял за идеологию и она мне больше запрещает писать "<?=", потому что я уже один раз обжёгся.

0
egorinsk, #
> xml

Мда, единственная ассоциация с таким унылокодом — поговрка про мышей и кактус. Вы эту конструкцию у индийских коллег подчерпнули?

0
nerezus, #
> Наоборот, php код в xml файле.
XML строится по данным, как правило ;) Так что пример из области фантастики имхо )
0
nerezus, #
И все же ответьте на вопрос. Что делают xml и php в одном файле?
+1
ArtemS, #
xml — это xslt, svg, rss и туева куча других технологий и форматов. Их содержание можно генерировать с помощью php. Если есть xml-острова в xhtml.
0
zhekanax, #
пример — темплейт для рендеринга рсс
0
chetzof, #
В php 5.3 он deprecated кстати если не ошибаюсь.
0
vladsm, #
0
magicstream, #
не deprecated, просто отключен по умолчанию. можно включить
в 6-том даже планируют удалить поддержку коротких тегов
+2
demongloom, #
ИМХО смарти как одно из простых решений еще долго будет на рынке движков шаблонов. Он прост, сильно распространен и легко найти верстальщика знает его или который сумеет справиться со смарти.

Порой этот фактор критичней чем производительность или скажем экранирование. Просто скинут эти проблемы на программистов/админов, что-бы те или подкрутили производительность или плетки выдадут, для обучения верстальщиков "|escape".
0
web4_0, #
Проблему шаблонизаторов давно уже забыл.
Когда сам делал проекты с нуля — да, использовал, но и то — ради красоты кода.
А теперь у нас есть верстальщик. Он вообще в PHP-код не заглядывает — дал нам свёрстанный макет, мы его сами внедряем в скрипты. Вот и все дела.
0
ibnteo, #
Такой подход на самом деле проще, верстальщику сложнее вставить сверстанный код, чем программисту. Правда бывают ситуации когда надо менять верстку в уже рабочих шаблонах.
–1
Aecktann, #
Объясните, почему вы сравниваете фреймворк на одном языке программирования с другим языком программирования без фреймворков?
0
zhekanax, #
Сравнивается удобство использования и функциональность шаблонизаторов.
И питон (джанго), и пхп скриптовые языки, так что сравнение, имхо, вполне уместное.
0
nerezus, #
> нет, использование более компактного <?= непреемлемо
Отчего же? Прямо так без обоснований?)
0
nerezus, #
Насколько я понял из лога выше, то причины не были придуманы(кроме неправильной работы с XML).
Но вместо отказа от <? можно просто работать с XML правильно. Это более верное решение проблемы ;)
0
VolCh, #
Что значит правильно?

'<?' — в XML стандартный префикс для инструкций обработки (Processing Instructions). Если в моем XML шаблоне содержатся такие инструкции и короткие теги PHP включены, то куда меня пошлет PHP (а потом и парсер XML)?
0
DmitryKoterov, #
Ну так выключите персонально для этого шаблона short_open_tag через ini_set… Верно ведь, что на типичном сайте XML-шаблонов значительно меньше, чем HTML-шаблонов?
0
VolCh, #
Если сайт на xHTML, то неверно ;) (переписку выше в комментах про вывод <?xml… > видел, ну это так, придирка) Но проблема в том, что шаблоны часто пишет не разработчик, более того разработчик может и не знать среду выполнения, может там переопределение параметров вообще запрещено (встречался такой, что например, не давал включить вывод ошибок в браузер).

Всё же лучше я буду писать шаблоны так, как считаю нужным, будучи уверенным, что в любой представимой среде хоть тут ошибок не будет, чем буду описывать в доках для будущих верстальщиков такие нюансы, как вывод <?xml… ?> через echo, да еще лишняя строчка в системных требованиях с настройкой которую сами разработчики PHP не рекомендуют включать.
+1
egorinsk, #
> Ну так выключите персонально для этого шаблона short_open_tag через ini_set…

Это вам индийские коллеги такое решение подсказали?

Кстати, по поводу того, что мол долго писать [?php echo — у меня вбито несколько сокращений в редактор, например [угловая скобка] [e] [Ctrl +B] — как раз всятавляет конструкцию [? php echo; ?], и код выглядит нормально, и печатать недолго.
–2
LifeOS, #
на некоторых хостингах сокращенная версия отключена.
нужно писать <?php=
0
Hint, #
Конструкция <?php= никогда не работала и, судя по всему, не будет работать (разработчики против).
0
LifeOS, #
да. ошибся
0
nerezus, #
1) Ошибка ;)
2) Никто не мешает включить их на уровне .htaccess
0
LifeOS, #
да. ошибся

short_open_tag = On
0
mazy, #
2 — только в случае Апача
0
nerezus, #
Если не апач, то никто не мешает настроить главный конфиг как душе угодно ;)
0
A_G_K, #
статья обсуждалась в LJ — community.livejournal.com/ru_php/1426579.html
–3
Makaveli, #
>необходимо отобразить массив и вывести текст по умолчанию, если этот массив пуст

А почему нельзя вывести массив через print_r? Навскидку, имхо читабильнее:

<?php
$a = array ('a' => 'apple', 'b' => 'banana', 'c' => array ('x', 'y', 'z'));
if (print_r (@$a, true))
{
  print_r($a);
}
else
{
  echo "No values";
}
?>


* This source code was highlighted with Source Code Highlighter.

По мне, так можно обойтись и вовсе одним print_r зачастую.
+1
zhekanax, #
Это слишком абстрактно, попробуйте print_r'ом вывести пункты меню.
+2
zhekanax, #
И рекомендую поменять if (print_r (@$a, true)) на if (!empty($a))
Лаконичнее, логичнее и красивее
0
graber, #
И рекомендую поменять if (!empty($a)) на if ($a)
Лаконичнее, логичнее и красивее
+3
zhekanax, #
DВ вашем случае получим
Notice: Undefined variable $a

Что, имхо, плохо :)
0
DmitryKoterov, #
Автор Симфони открыл для себя Джангу, эврика! :-) Почему бы тогда просто не писать на Джанге? ИМХО она лучше, чем конкретно Симфони — по крайней мере, в Джанге некривая ОО-модель, а также весьма элегантный ORM (хотя в Симфони Doctrine внедрять, я с ним не работал, а вот с Propel — пришлось и много). Если бы у меня был выбор только между Симфони и Джангой, а бы выбрал последнюю — даже учитывая всю мою любовь к PHP…
0
VolCh, #
Ну глядишь увидим в следующем релизе Симфони еще и влияние Джанги, как сейчас видно влияние Рельс ;) Что плохого?
+1
witdex, #
Неа, в соответствии с выходом пхп 5.3 будет отходить от проектирования такиго как в ror-e, теперь это будет явная цель на java fw куда и стремиться сам php. Будет набор standalone components with loaders и соответственно сам фреймворк
0
develop7, #
А Sensio и на питоне пишет, не думайте. Но больше всё-таки (AFAIK) на PHP.
Кстати, а что в symfony не так с «ОО-моделью»? Ну, то есть, где конкретно она кривая?
+1
witdex, #
Sensio о Django знает давно) Другое дело что там не нашлось чего внедрят, т.е. такого революционного как с рельсами но поводу Symfony 2 уже не будет inspired by RoR, исходники буквально неделю назад выложил Фабьен, теперь это будет нечто похожее на набор компонентов как ZF, но с CLI.
Что касается ORM, то propel действительно очень уступает доктрине, во-первых с его criteria, и не явную работу с сложными джойнами, во-вторых доктрина это действительно похоже на ORM с таких яп как java.
–2
maxic, #
Опять велик.
Ну сделайте класс своего api и используйте прелести php.
Выгода?
Сократит код, тот кто не хочет «рыться» и изучать api проекта, может «по быстрому» использовать… чистый php (будем считать по умолчанию гораздо распространенным шаблонизатором :). Да пора забыть про шаблонизаторы. API имхо, api.
А шаблонизаторами не всегда можно свободно «оперировать» и всё описать, все же php&api гораздо гибче.
0
DeMx, #
Постоянно слышу, как люди хвалят шаблонизаторы и даже пишут что-то свое, но я все никак не могу их понять. %)

Почему «использование более компактного
+2
DeMx, #
чорт, все обрезалось))
0
egorinsk, #
Dwoo — тоже дурной, состоит из кучи файлов, у меня не раз бывало, что в нем блоьше файлов чем в остальных компонентах сатйа.
0
davojan, #
Жаль, что нет сравнения скорости с шаблоном на чистом PHP.
0
zhekanax, #
А смысл, если автор считает его невзможным в исользовании?
0
Vanav, #
0
zhekanax, #
Если интересно, есть перевод подведения итогов habrahabr.ru/blogs/php/76021/
–6
zupernintendo, #
Эти отговорки про «длинность» и «громоздкость» конструкций просто уже клише какоето для оправдывания существования шаблонизаторов.
Автор Twig — лох, потому-что писать шаблонизатор из-за незнания возможностей php и своих эстетических предпочтений будет только лошара.
Автор говорит про простоту шаблонизатора — на самом же деле предоставляет еще один шаблонизатор (да еще и на php) со своими фичами и граблями, большинство из которых не будет использоватся за ненужностью.
+2
nekt, #
Кто же разряды разделет запятыми? Если переводите — замените их на пробелы.
Я долго пытался понять почему Twig генерит всего три с половиной шаблона в секунду и при этом является самым быстрым.
–1
TravisBickle, #
Он не является самым быстрым ;-)
0
zhekanax, #
конечно исправлю, спасибо
0
tarutin, #
меня мой шаблонизатор совершенно устраивает, использовал его довольно объемных проектах, возникли только некоторые желательные улучшения, которые я добавлю в ближайшем будущем
примерно сейчас это выглядит так:

{foreach name=page source=#sctucture}
   {if #page.isHide=='0'}
      <li>{#page.name}</li>
   {/if}
{/foreach}

а хочу:

{foreach name=page source=#sctucture/isHide=='0'}
      <li>{#page.name}</li>
{/foreach}


(то есть добавить чуточку xslt))
0
tarutin, #
честно скажу, мало проводил исследований других шаблонизаторов, просто сделал как бы мне было удобно. хотя работал с xslt больше двух лет и очень остался доволен. но объемный код xslt расстраивал конечно и усложнял работу с сложными проектами, особенно под конец рабочего дня, когда глаза не могу найти в коде то, что нужно))
0
Bal, #
Плотно пощупал тут Twig. Неплох по скорости, синтаксис по умолчанию более удобный, чем у Smarty. Но убило напрочь то, что так и не понял как без правки самого Twig'а, как вводить именованные параметры в тэгах. Т.е., скажем,

{% module name=«my_module» id=$id %}

Варианты, типа

{% module name as «my_module» id as id %}

смотрятся чудовищно.

Если бы не это, попробовал бы Twig в качестве шаблонизатора в новых классах своего фреймворка.

Захотел также, для сравнения, оценить Quicky, но с удивлением обнаружил, что релиз не обновлялся с весны. Тогда это было очень сыро и недоработано. Проект скорее мёртв, чем жив?



Похоже, пока по-прежнему будут сидеть на Smarty :)
0
CAH4A, #
Что за фреймворк? :)
0
Bal, #
Как обычно, свой собственный :) — bors.balancer.ru/



А по теме передачи параметров, без хака Twig'а родил конструкции вида:

{% module name:«my_module» id:this.id %}

Но, вообще, повозиться для полной поддержки Twig'а много придётся. Тэги, фильтры, блоки…
0
Methos, #
Я в своих проектах использую Quicky. Очень нравится.
0
tenshi, #
я замерил этот ваш твиг с шаблоном чуть по сложнее чем «привет мир». в результате он только компилирует быстрее смарти3, а исполняется дольше.

исполнение в 3 раза медленнее хслт, который в 3 раза медленнее лапши на пхп. оно и не удивительно, там столько классов интерпретатору разгребать приходится… на каждый чих по классу.
0
zigor, #
А кто-нибудь уже использовал Twig на больших и нагруженных проектах или слышал об использовании в той или иной компании/проекте?

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

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

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