agorlov18 мая 2010 в 07:09

Введение в шаблонизатор Blitz

5 мин

11K

Высоконагруженные системы *

Перевод

+31

147

Комментарии 147

Morfi 18 мая 2010 в 07:23

К сожалению документация как на русском та и на английском устарели.

agorlov 18 мая 2010 в 07:30

в английской доке есть апдейты про плагины от апреля 2010

Morfi 18 мая 2010 в 07:38

Спасибо, не заметил, нашел перед оглавлением =)

MisterX 18 мая 2010 в 07:24

Хотелось бы в тестах видеть еще Twig.

agorlov 18 мая 2010 в 07:28

мне тоже интересно, исходные коды бенчмарка есть, может кто-нить проверит?

brook 18 мая 2010 в 08:04

Есть тесты тут — fabien.potencier.org/article/35/templating-engines-in-php-follow-up
Как видно проигрывает чуть чуть native code, но не сильно.

MisterX 18 мая 2010 в 09:20

Я имел ввиду с Blitz, то есть в тех бенчмарках что в топике, хотелось бы видеть Twig.

Petrik 18 мая 2010 в 07:44

И Quicky тоже не хватает в тестах

anr 18 мая 2010 в 09:50

он живой? в смыле проект)) я когда-то пробовал, но не прижился он, частично из-за автора проекта.

anr 18 мая 2010 в 09:51

сейчас использую blitz и он мне очень нравится)

s0b3r 18 мая 2010 в 10:15

а квики принципиально отличается от смарти?

Petrik 18 мая 2010 в 13:19

В нем ставка на скорость сделана, а раз blitz ориентируют как высокопроизводительный шаблонизатор, то почему бы и не сравнить с квики?

s0b3r 18 мая 2010 в 16:34

согласно местному бенчмарку квики не намного быстрее
habrahabr.ru/blogs/php/55207/

s0b3r 18 мая 2010 в 16:34

чем смарти

jrwisard 18 мая 2010 в 07:53

У меня в коде с незапамятных времен живет такая функция:

function parse($str, $variable)
{
	if (is_array($variable))
	{
		foreach($variable as $name => $var)
		{
			$str = str_replace("{{".$name."}}", $var, $str);
		}
	}

	return $str;
}

somniator 18 мая 2010 в 08:03

У меня такой кусок:

/**
 *  Применение шаблона.
 *  
 *  Шаблон представляет собой HTML-файл с PHP-вставками. Во вставках
 *  можно использовать переменные из массива $variables, на основе каждого
 *  элементв key => value определяется переменная с именем $key и значением
 *  $value.
 *  
 *  @param $file Имя файла шаблона.
 *  @param $variables Массив переменных и их значений, доступных в PHP-вставках
 *      шаблона.
 *  @return HTML-код, созданный на основе шаблона и переменных $variables.
 */        
function template_render($file, $variables) {
    extract($variables, EXTR_SKIP);
    ob_start();
    require "$file";              
    $contents = ob_get_contents();  
    ob_end_clean();                 
    return $contents;               
}

insa 18 мая 2010 в 08:08

ну, можно сократить на пару строк

function template_render($file, $variables) {
extract($variables, EXTR_SKIP);
ob_start();
require "$file";
return ob_get_clean();
}

brook 18 мая 2010 в 08:07

гениальный шаблонизатор

LoneCat 18 мая 2010 в 08:32

Можно ее оптимизировать! :P

function parse($template, array $vars) {
  $keys = array_keys($vars);
  foreach($keys as &$key) {
    $key = '{{'.$key.'}}';
  }
  return str_replace($keys, $vars, $template);
}

Zibx 18 мая 2010 в 08:48

На 200 000 проходах при трёх переменных в массиве вышло:
4.16662 секунд для того что было
4.01965 секунд для того что стало
1.39104 через коллбек

При 6 переменных соответственно:
6.50506
5.75486
1.40864

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

Zibx 18 мая 2010 в 09:30

Не читайте это. Тут я ступил с кодом. У LoneCat оптимальный код.

Zibx 18 мая 2010 в 08:38

Мой работает в n раз быстрее судя по тестам, где n — число элементов массива. Косяк правда что пришлось засрать пространство вот коллбеком, но это вроде именно тот случай, когда игра стоила свеч. (хотя может и экономия на спичках)

 function ratherFastVars( $text, $vars ){



  if( ($p1 = mb_strpos( $text, '%' )) !== false ){

    $arr1 = array_keys( $vars );

    $arr2 = array_values( $vars );

    array_walk( $arr1, 'wrapperCallback');

    $text = str_replace( $arr1, $arr2, $text );

  }

  return $text;

 }



$wrapperCallbackShit = array( '{{', '}}' );

function wrapperCallback( &$val ){

    global $wrapperCallbackShit;

    $val = $wrapperCallbackShit[0]. $val .$wrapperCallbackShit[1];

}

LoneCat 18 мая 2010 в 08:43

Не, callback тут наоборот съедает часть преимущества, быстрее сделать замену через foreach(&), и callback не нужен.

Zibx 18 мая 2010 в 08:51

Не, цикл исполняемый интерпретатором пошагово и внутренний цикл исполняемый уже процессором — две большие разницы. Хотя я тестировал на пхп 4, может они подтянули это дело несколько.

LoneCat 18 мая 2010 в 08:54

Ну на php4 незнаю, а на php5 скорость foreach по сравнению с callback-функциями больше в разы, так как опускается момент вызова функции, что как-бы и при внутреннем цикле все равно делать нужно.
З.Ы.

Хотя я тестировал на пхп 4

я смотрю у вас консервативные взгляды на php :)

Zibx 18 мая 2010 в 09:08

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

Zyava 18 мая 2010 в 11:19

То есть Вы продолжает писать на PHP4, я правильно понимаю?

LoneCat 18 мая 2010 в 09:00

Перепроверил, был неправ, действительно c callback быстрее (на php5.2.11 — в два раза), для меня это откровение, помню в свое время отказался от его использования из-за того что он проигрывал простому foreach.

LoneCat 18 мая 2010 в 09:08

Вы меня нечестно впутали :) У вас когда в шаблоне нет '%' функция вообще не отрабатывает, оттуда и весомое преимущество :) foreach все-таки быстрее.

jrwisard 18 мая 2010 в 13:35

Целую ветку наоптимизировали функцию, которая писалась больше 5 лет назад и использовалась в самых простых случаях на 10-12 переменных и пару-тройку шаблонов. Я конечно понимаю, что круто и производительность увеличивается в разы, но порядок-то величин и так мизерный! А для сложных шаблонов, между прочим, используется Smarty, который был выбран главным образом из-за циклов и условий.

conturov 18 мая 2010 в 08:14

Вот еще про Blitz есть статья на Хабре: habrahabr.ru/blogs/webdev/18695/

DeusModus 18 мая 2010 в 08:59

Здесь автор кроме той же картинки приводит примеры. С примерами всегда проще знакомиться с новым.

max_m 18 мая 2010 в 08:15

>Один из его авторов Алексей Рыбак fisher, он же автор php-fpm (PHP-FPM недавно добавили в ядро PHP5.3).

php-fpm разработал Андрей Нигматулин

agorlov 18 мая 2010 в 08:38

сори, поправлю

Rusan 18 мая 2010 в 08:41

а добавил в ядро tony2001

taliban 18 мая 2010 в 08:30

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

basilisk 18 мая 2010 в 10:07

Согласен.

Ещё мне не нравится реализация условий. ИМХО конструкция {{ if($_first,'',',') }} весьма неудачная. Как будет чувствовать себя верстальщик, если его попросят заменить запятую на какую-нибудь графическую пимпочку или что-нибудь ещё более громоздкое?

{{ if($_first,'','<img src=«images\pimpa.png» width=«5» height=«5» alt="">') }}

Так? Или можно сделать как-то по другому, исправляя только шаблон?

В том же самом Смарти это красивее:
{if !$smarty.foreach.block.first}<img src=«images\pimpa.png» width=«5» height=«5» alt="">{/if}

Красивее потому что:
* зачастую верстальщик не должен или боится исправлять что-либо внутри фигурных скобок — ведь можно всё сломать :)
* не мешает работе всевозможных syntax highlighter'ов в редакторах, код становится визуально понятнее.

Morfi 18 мая 2010 в 11:10

В Blitz есть конструкции вида
{{ IF cond }}
…
{{ ELSE }}
…
{{ END }}

basilisk 18 мая 2010 в 11:15

О! Так лучше, зря об этом не было упомянуто в статье.

Беру свои слова обратно.

taliban 18 мая 2010 в 14:42

все равно я циклы имел ввиду, условные конструкции самое простое что можно представить, верстальщики их прекрасно понимают, сложней дело обстоит с вложенными циклами

fisher 19 мая 2010 в 14:00

цикл = блок. вложенные циклы = вложенные блоки.

shagguboy 18 мая 2010 в 08:31

groups.google.com/group/highload-php-en/msg/29a9a35bca58da55?pli=1
> That'd be great. My PHP is a mess at the moment through trying to
> configure it with php-fpm. I'd like to be able to tidy it up.

«Still»?
It never was planned to be included into 5.3.3 in the first place.

But it seems that 5_4 branch is ready to accept FPM, which means the very
first release from it will come with FPM out of the box.

—
Wbr,
Antony Dovgal
— pinba.org — realtime statistics for PHP

PavelRadaev 18 мая 2010 в 08:45

Уважаемый автор, что по вашему такое «логика приложения»?

Вот допустим надо вывести в что-то в два столбца в таблице, причем это нельзя сделать «правильным путем» (для сложности примем что ячейки таблицы снабжены разными атрибутами style) — просто размножить одну ячейку не получится.

Логика, которая будет рубить набор элементов на две части а затем засовывать получившееся в две ячейки — это логика приложения или логика отображения?

Другой вопрос: Если рассматривать MVC, то где предполагается держать вот этот например код:

$data = array(
0 => array(
'block' => array(
0 => array('name' => 'Dude'),
1 => array('name' => 'Sobchak'),
2 => array('name' => 'Donny')
)
),
);

$template = new Blitz('some.tpl');
echo $template->parse($data);

?

В контроллере или во вьюхе?

saterenko 18 мая 2010 в 09:18

Пользуюсь Blitz уже года 3 наверное. Ни разу небыло случая, чтобы нельзя было реализовать функционал через этот шаблонизатор. Более того, я использую только вывод пеерменных и блоки, всё, новомодные if и т.п. считаю в шаблоне лишним. Большая часть данных в шаблон попадает из базы без модификаций.

Для меня это идеальный шаблонизатор, который не засоряет шаблон мусором.

PavelRadaev 18 мая 2010 в 09:33

видимо вы не туда ответили.

agorlov 18 мая 2010 в 09:27

По первому вопросу, очевидно, логика отображения рубит, а логика приложения поставляет данные на рубку.
По второму: я бы этот код отнес ко View, в некоторых, простых случаях можно и в Controller поместить. Это решение принимает разработчик на свое усмотрение. Шаблонизатор не диктует применение какого-либо паттерна.

PavelRadaev 18 мая 2010 в 09:36

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

PavelRadaev 18 мая 2010 в 09:56

Давайте попробуем разобраться с терминологией?!

логика приложения это: «показать юзеру набор результатов»
логика представления это: «как именно показать, в каком формате и тд и тп»

согласны?

agorlov 18 мая 2010 в 10:17

Да.
По поводу отделения: в Blitz невозможно поместить логику приложения в шаблоне.
Если взять Smarty или PHP, то там в шаблоне можно целю программу написать.

sergey_novikov 18 мая 2010 в 11:20

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

Iskin 18 мая 2010 в 09:00

По моему отсутствие нормальных операций, только убивает разделение логики. Например, мне нужно посчитать полупрозрачность комментария в зависимости от кол-ва минусов (ну вы поняли ;) ) — это логика чисто для view (максимум, для helper’а). Введение ещё одного слоя «контроллера вида» просто бессмысленное усложнение.
Тем более хороший код должен строится на хорошей архитектуре и хорошем стиле и традициях внутри коллектива, а не на ограничениях.

PavelRadaev 18 мая 2010 в 09:42

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

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

tenshi 18 мая 2010 в 20:06

покажи шаблон

PavelRadaev 19 мая 2010 в 04:17

какой?

tenshi 19 мая 2010 в 07:24

какой-нибудь. думаю вы неправильно их готовили

PavelRadaev 19 мая 2010 в 07:36

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

tenshi 19 мая 2010 в 12:06

значит всё-таки неправильно

PavelRadaev 19 мая 2010 в 12:26

раз уж вы столь категоричны — потрудитесь ответить на вопрос: А как правильно?

tenshi 19 мая 2010 в 12:35

я уже показал на примере хслт

PavelRadaev 19 мая 2010 в 12:40

я не знаком с xslt.

tenshi 19 мая 2010 в 12:46

очень зря. его идеология в корне отличается от «традиционной»

s0b3r 18 мая 2010 в 10:38

эту логику можно реализовать в js, например

всё зависит от качества проекта… вот для своих я использую нативные шаблоны и не парюсь… если нужно сделать что-то очень быстро, можно даже подключить модель из шаблона =) а для хорошего проекта, где есть верстальщики и много новых «тем» (представлений) лучше всё-таки использовать что-то вроде блитца

можно, кстати, сделать функцию для расчёта этой полупрозрачности, и использовать её в шаблоне… и никакого «контроллера вида» не надо =)

PavelRadaev 18 мая 2010 в 10:56

да ладно вам.

вот например кусок «кода контроллера»

public function rssAction() {
$view = new My_View();
echo $view->render('Rss.phtml');
}

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

Iskin 18 мая 2010 в 11:10

Всё равно много лишнего, сравните:

def show
  @feeds = Rss.all
end

PavelRadaev 18 мая 2010 в 11:11

:) суть та же.

s0b3r 18 мая 2010 в 16:25

я не говорил ничего против, если что, я всего лишь высказал мнение насчёт вариантов того, как не смешивать контроллер и представление… а то, что я иногда использую вызовы моделей прямо из шаблонов — это о цене вопроса… добавить вызов модели в один шаблон или в несколько(много) контроллеров? моя архитектура позволяет мне решить эту дилемму первым способом, поэтому иногда я им пользуюсь

ну вот мой кусок контроллера, простейший пример

<?php
require_once ROOT .'models/faq.class.php'; // подключение модели

$aFaqs = Faq::getList();

include $this->inject('misc/faq'); // тут подключение шаблона

только к чему это? я знаю, что такое контроллер =)

tenshi 18 мая 2010 в 20:08

зачем вам вообще контроллеры?

tenshi 18 мая 2010 в 20:04

view != template

карандаш != лекало

Ruzin 19 мая 2010 в 04:56

Поддерживаю!

Спрашивается, чем плох сам PHP, как шаблонизатор?

Вариантов шаблонизации море, на все вкусы:

template.tpl:
===========
<?php
$qqq = <<<QQQ
{$data['fio']}
QQQ;
echo $qqq;
===========

controller.php:
===========
<?
…
$data['fio'];
require ('template.tpl')
===========

или на функциях:
template.tpl:
===========
<?php
function fio($data) {
$qqq = <<<QQQ
{$data['fio']}
QQQ;
return $qqq;
}
===========

controller.php:
===========
<?
…
$data['fio'];
require_once ('template.tpl')
echo fio($data);
===========

или на классах:
Template.class.php:
===========
<?php
class FioTemplate {
…
function render($data) {
$qqq = <<<QQQ
{$data['fio']}
QQQ;
return $qqq;
}
===========

controller.php:
===========
<?
…
$data['fio'];
require_once ('FioTemplate.class.php')
$fio = new FioTemplate();
echo FioTemplate->render($data);
===========

По-моему, отличный язык PHP, и предназначен для шаблонизации :)
Есть и циклы и условия, использовать их только надо с умом и к месту.

Iskin 19 мая 2010 в 05:02

Бесспорно. Если всё же Вы пишите на PHP (а не Ruby или Python), то сам PHP прекрасно подходит под шаблонизатор.

sqrt 18 мая 2010 в 09:12

взглянул на слово «Blitz», сразу подумал что статья про создание игры на Blitz3d)

keltanas 18 мая 2010 в 09:13

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

2. Не совсем понятно, каким образом тестировались шаблонизаторы? Скачал предложенный «бенчмарк», но так и не нашел точки входа для самого «бенчмарка».
В ходе тестирования замерялось время перекомпиляции шаблонов, или отображение уже скомпилированных?

3. Если Blitz написан на C, то я бы сильно удивился, если бы он не работал быстрее смарти. Но, какой шаред-хостинг (а именно такой используется для большинства рядовых сайтов) установит у себя Blitz?

saterenko 18 мая 2010 в 09:22

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

2. Через ab, это видно на картинке. Blitz не компилирует шаблоны, он их каждый раз «парсит».

3. А при чём тут шаред-хостинг?

keltanas 18 мая 2010 в 09:46

1. Это и так понятно. Любой шаблонизатор отделяет _бизнес_ логику от представления.

2. Протестил у себя на денвере (Apache 2.2.4, PHP 5.2.13). Блитз отсюда (http://alexeyrybak.com/blitz/win32-binaries/ — v0.6.10):
* Smarty2: 124.96 rec./sec.
* Php: 187.98 rec./sec.
* Php include: 131.95 rec./sec.
* Blitz: 175.07 rec./sec.
Впечатляет, но не так, как на картинке в начале поста… ))

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

PavelRadaev 18 мая 2010 в 09:49

1. шаблонизатор сам по себе ничего не отделяет. а в случае с блитзом ещё и добавляет дополнительный слой приложения, называемый «контроллер представления» — тем самым увеличивая косты на саппорт.

agorlov 18 мая 2010 в 10:11

Слой «контроллер представления» уже есть, если вы используете шаблонизатор.

Smarty:

  $tpl = new Smarty();
  // вот он слой: контроллер представления - это подготовка данных для шаблона
  $tpl->assign('var', 'Hello');

  $tpl->display('template.tpl');

в случае с Blitz:

  $tpl = new Blitz('template.tpl');
  //слой: контроллер представления
  $data = array('var', 'Hello');

  $tpl->parse($data);

В случае с Blitz меньше логики будет в шаблоне, но больше строчек после коммента «слой: контроллер представления».

PavelRadaev 18 мая 2010 в 10:14

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

PavelRadaev 18 мая 2010 в 09:46

1. что означает «отделять логику от представления» — логику чего? логику представления от самого представления? Кому проще понимать шаблон? Верстальщику или разработчику? Какая реальная польза от этого? Как это разделение увеличит скорость разработки? Как это разделение упростит поддержку решения? Для того, чтобы вывести дату в другом формате например надо будет внести изменеия в двух файлах?

saterenko 19 мая 2010 в 10:06

Вы не любите шаблоны? Вы просто не умеете их «готовить»…

Thomas 18 мая 2010 в 09:52

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

fisher 19 мая 2010 в 10:24

по куче шаблонов как раз не надо раскидывать — делаете вложенные блоки или fetch.

про XSLT. мне кажется, что blitz во многом наследует «концепцию» XSLT, только всё очень сильно упрощает. назовите мне прелести XSLT — и я попробую привести аналогии.

tenshi 19 мая 2010 в 12:09

в блитзе насколько я понял структура фиксированная, а в xslt зависит от переданных данных

fisher 19 мая 2010 в 14:03

если что-то не передать — оно не будет «проитерировано». звучит как-то тривиально, но в чём суть, я что-то не могу понять?

tenshi 20 мая 2010 в 08:03

ну, например, нужно нарисовать дерево. соответственно, корень, ветви и листья должны быть нарисованы по разному. глубина — произвольная. как это реализовать?

fisher 20 мая 2010 в 17:44

такие штуки делаются по-разному, например, через рекурсивную структуру шаблона
phpclub.ru/talk/showthread.php?s=&threadid=94234&perpage=40&pagenumber=2
мой предпоследний комментарий — он не 100% верный, но думаю суть будет ясна.

tenshi 20 мая 2010 в 18:18

а если надо чтобы ссылки для заголовков листьев и ветвей формировались одинаково?

fisher 21 мая 2010 в 04:20

разве это имеет какое-то принципиальное значение? всегда для отображения дерева его либо надо разворачивать через стек либо писать рекурсию. всё остальное — как там будут отличаться ссылки и так далее — это всё мелочи, ну дополнительное условие.

tenshi 21 мая 2010 в 07:42

я это к тому, что в твоём шаблоне есть дублирование… а чтобы от него избавиться — и без того нетривиальная логика ещё сильнее усложнится.

а в какой момент происходит экранирование специальных символов?

fisher 22 мая 2010 в 09:29

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

tenshi 22 мая 2010 в 11:56

в том примере, что ты кинул — в двух местах выводится title (допустим мы хотим каждый сделать ссылкой) и в двух — li

у… без автоэкранирования считай куча xss обеспечено.

fisher 22 мая 2010 в 14:48

ты в шаблоне можешь cказать {{ escape($var) }} вместо {{ $var }} и всё. либо передавать экранированные значения. отсутствие автоэкранирования не ведет к xss само по себе ;)

про дублирование — я не понимаю о чем вообще спор. может быть ты приведешь какой-то свой пример, чтобы мне стало понятно, что именно ты считаешь ценностью и чего я не могу сделать при помощи blitz?

tenshi 23 мая 2010 в 09:30

ведёт. ибо рано или поздно кто-нибудь забудет проэкранировать.

эм… я хочу чтобы каждая сущность определялась только в одном месте. у тебя же сущности «ссылка ветви/листа дерева» и «элемент списка в дереве» определяются в двух местах. от этого конечно можно избавиться… но ещё большим усложнением…

etc 18 мая 2010 в 10:03

В плане формата шаблонов писал нечто подобное, только на PHP.

odiszapc 18 мая 2010 в 10:23

А я использую нативные PHP шаблоны. Они мне понятны и просты. Тут каждый сам для себя выбирает.

fledgling 19 мая 2010 в 19:13

>А я использую PHP как шаблонизатор. Он нативен, понятен и прост.
fxd.

highw 18 мая 2010 в 10:50

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

Вот с первого взгляда не совсем очевидны плюсы перед тем же смарти (хоть он мне и не очень нравится генерированным мусором) все же он удобней чем этот.

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

agorlov 18 мая 2010 в 11:18

Хабр нам всем близок, не считаю зазорным рассказывать о том, на чем он построен.

Сами используем смарти и довольны. Даже уже пробуем 3ую версию.

Но есть у нас и проблема, которая подталкивает к поиску — с ростом функционала шаблоны становятся трудно-поддерживаемыми.

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

Поэтому в новых разработках, у себя будем пробовать.

К анализу в данный момент я не готов.

Но если интересно сравнить, рекомендую скачать: alexeyrybak.com/blitz/lebowski_bench.tar.gz — там реализован очень простой сайт с использованием всех перечисленных на графике шаблонизаторов.

Zyava 18 мая 2010 в 11:24

Как следствие, шаблоны с ростом проекта не превращаются в кашу.

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

Orion189 18 мая 2010 в 11:40

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

1. Дофига фигурных скобок.
2. Сам шаблон в случае Smarty выглядит интуитивно понятнее.
3. Выносить контроллер шаблона в отдельный слой в случае РНР — сомнительная польза.

По поводу п.3: сам сейчас разбираюсь с Flex-фремворком Mate. Там тоже хорошим стилем считается создание дополнительных PresentationModel's (по сути — эти же самые контроллеры видов). Но там это продиктовано практической пользой, завязанной на событийную модель и саму идею фремворка. Более того, сами PresentationModel's взаимодействуют со всеми частями архитектуры MVC, а не только с шаблонами.

agorlov 18 мая 2010 в 11:54

Открывающие и закрывающие скобки — настраиваются, можно сделать как в смарти.

Orion189 18 мая 2010 в 11:55

Тогда первый пункт вычеркиваем))

Sone 18 мая 2010 в 12:44

По заголовку подумал что речь идет про ru.wikipedia.org/wiki/Blitz_BASIC

pixxxel 18 мая 2010 в 12:51

Может быть я чего-то не понимаю, но ведь шаблон смарти компилируется в чистый php. И как может blitz работать быстрее чистого php?
Понимаю что меня заминусуют, но мне действительно интересно.

basilisk 18 мая 2010 в 13:10

И как может blitz работать быстрее чистого php?

Потому что написан на C.

pixxxel 18 мая 2010 в 13:14

А на чем написан php?

basilisk 18 мая 2010 в 13:21

Тоже на C

basilisk 18 мая 2010 в 13:28

Сначала неправильно ваш вопрос понял, простите тормоза :)

Разница по сравнению с чистым PHP возможна по той простой причине, что Blitz может иметь гораздо более простой анализатор файла-исходника.

Грубо говоря, для примитивнейшего шаблонизатора нам надо простой C код: прочитать файл, str_replace, сплюнуть на вывод.
PHP файл же будет долго и вдумчиво анализироваться и интерпретироваться.

Это в теории, сам я сорцы не ковырял :)

tenshi 18 мая 2010 в 20:29

+смарти генерирует не слишком оптимальный код…

akalend 18 мая 2010 в 21:21

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

Stormbringer 18 мая 2010 в 12:52

Просмотрел документацию по диагонали, не нашёл одного интересующего момента — возможно ли для шаблона наподобие следующего:

{{ $var1 }} hello {{ BEGIN block }} {{ $var1 }} {{ END }}

одной строкой задать значение, которое примет $var1 во всем шаблоне — как вне блока block, так и внутри него.

В данный момент в качестве блочного шаблона для РНР использую www.source-code.biz/MiniTemplator/, там установка значения для переменной во всем шаблоне делается на ура.

Morfi 18 мая 2010 в 13:58

Есть глобальные переменные, и есть локальные.

fisher 19 мая 2010 в 10:13

дело не только в локальных и глобальных переменных.

есть такой режим, когда не найдя переменной на текущем уровне видимости локальных переменных, блиц поднимается выше и ищет там. макисмальный уровень таких лукапов «назад-вверх» ставится переменной blitz.scope_lookup_limit

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

1) Variable scope

You don't need to pass parameters from parent to child contexts
anymore. When blitz executor fails on finding corresponding parameter
in the current iteration data, it will go upper back to parent and
check if variable is there. If it fails again — upper check again. The
depth of «back» lookups is controlled by blitz.scope_lookup_limit,
which is set to zero by default (this meat that feature is disabled by
default)

DriverX 18 мая 2010 в 14:14

А почему CTPP в бенчмарках нету? У него же есть тоже модуль для php и специально для высоконагруженных систем.

akalend 18 мая 2010 в 21:16

потому что когда делались бенчмарки, проект ctpp как бы был за кадром. На то время — ctpp был не очень быстрым. Вроде как Шетухин его подправил и вторая версия пошустрее. У меня была идея, и Андрей был не против подправить синтаксис шаблонизатора в более приближенное к смарти. Но потом как-то мою идею не поддержало начальство и это дело заглохло.

DriverX 18 мая 2010 в 23:31

Т.е. получается результаты прохождения бенчмарка немного несвежие? ctpp 2 уже давно отрелизился и активно используется на ряде hl-проектов. Могу ошибаться, но мне всегда казалось, что Андрей негативно отзывается о Smarty =)
Конечно было бы хорошо увидеть его тоже в результатах тестирования.

akalend 19 мая 2010 в 14:09

Могу ошибаться, но мне всегда казалось, что Андрей негативно отзывается о Smarty =)

Назови мне того, кто о нем отзывался не негативно…
Моя мысль была: использовать синтаксис приближенный к смарти, и я предложил свою помощь. Он более распростаненный, нежеле перловский HTML::Template
Конечно было бы хорошо увидеть его тоже в результатах тестирования.Несомненно, так как они одного класса…
сравнение со всеми РНРшными шаблнизаторами — это популизм. Достаточно одного смарти и еще одного-двух самый «быстрых»…

притом методология сравнения должна включать не только циклы, а:
— вложенность блоков
— инклуды
— калбэки
— плагины

в общем тут надо подумать… мне так «с неба» трудно что подсказать

fisher 19 мая 2010 в 05:00

тесты устарели, их надо менять. это кропотливая работа, но я это сделаю. насчет cttp — когда-то давно cttp v1 тестировался и ничего выдающегося не показал. после этого прошло много времени, недавно я собрал новую версию, но почему-то мой старый тест отказался работать правильно с новым cttp2. если бы кто-то просто мне прислал кусок для cttp2 или пофиксил мой тест для старого cttp (cм lebowski-bench ) — я был бы ему премного благодарен.

fisher 19 мая 2010 в 05:00

о, я даже называю его неверно — ctpp конечно :)

akalend 19 мая 2010 в 14:10

Леша, я тоже ошибался…

akalend 19 мая 2010 в 14:15

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

Было бы хорошо, чтоб это сделал автор статьи, ты и так очень занят. А те кто давно используют блиц и без тестов знают, что он самый быстрый из всего доступного… Жаль, что Onk не хочет открывать свою поделку.

akalend 18 мая 2010 в 20:58

1) Информация опоздала как минимум года на три…
2) это не самый быстрый шаблонизатор, есть быстрее, к сожалению автор его не хочет отдавать на ОпенСоурс
3) Говоря о блице, необходимо расказать об альтернативах, например cttp en.wikipedia.org/wiki/CTPP
4) хотелось бы услышать и недостатки… а то уж, слишком радужные впечатления.

akalend 18 мая 2010 в 21:18

Жаль что автор взял готовые бенчмарки с сайта А.Рыбака, а не сам что либо сделал…

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

tenshi 18 мая 2010 в 22:01

hello {{ BEGIN block }}{{ if($_first,'',',') }} {{ $name }} {{ END }}.

это называется никакой логики в шаблонах?!7

вот так было бы элегантней:

[template match="/"]hello [apply-templates mode=«comma-separated»/][/template]

универсальная обвязочка:

[template match="*" mode=«comma-separated»], [apply-templates select="." /][/template]
[template match="*[1]" mode=«comma-separated»][apply-templates select="." /][/template]

PavelRadaev 19 мая 2010 в 08:47

«элегантней» ??? вы издеваетесь?

hello <?php echo implode(', ', $names)?>

fisher 19 мая 2010 в 10:51

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

PavelRadaev 19 мая 2010 в 11:21

Да ладно, Алексей. Смесь с тем же успехом станет ещё запутаннее в шаблоне с блоками (с-ничего-не-говорящими-через-пару-месяцев названиями блоков — что ещё хуже) и в управляющем этим шаблоном коде; и когда в смеси пхп+хтмл можно обойтись одним ифом, то в том же blitz придется нарисовать блок в шаблоне и добавить тот же иф в управляющий код.

И я говорю не о «производительности», а о том, чтобы иллюзий не питать о возможности разделять и властвовать используя шаблонизатор. Сложность будет нарастать в любом случае — с шаблонизатором или без него. Другое дело, что сложность смеси пхп+хтмл ниже сложности смеси пхп+хтмл+логика шаблонизатора.

PavelRadaev 19 мая 2010 в 11:23

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

tenshi 19 мая 2010 в 12:25

практика показывает, что рядом с одним ифом всегда появляется второй, третий…

PavelRadaev 19 мая 2010 в 12:26

аналогично в шаблоне рядом с одним блоком появляется второй, третий… и в «контроллере шаблона» те же вилки

tenshi 19 мая 2010 в 12:35

не «контроллер шаблона», а всё ж «вьюха».

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

PavelRadaev 19 мая 2010 в 12:37

то есть будет два шаблона, которые незначительно отличаются? а над ними будет какая-то общая логика, которая вилками будет выбирать один из шаблонов, так?

tenshi 19 мая 2010 в 12:44

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

akalend 19 мая 2010 в 14:19

Алексей,
я сделал вывод, что на Хабре трудно что либо доказать, особенно если это связано с hiload. По этому на дискуссии уже стараюсь не поддоваться.

Но, спасибо, что заглянул…

tenshi 19 мая 2010 в 12:26

а теперь сделай из каждого имени ссылку на профиль

PavelRadaev 19 мая 2010 в 12:27

сначала сам сделай, эллегантным способом.

tenshi 19 мая 2010 в 12:28

я добавлю лишь один шаблон:
[template match=«name»][a href="?user={.}"][apply-templates/][/a][/template]

PavelRadaev 19 мая 2010 в 12:35

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

tenshi 19 мая 2010 в 12:40

на вход приходит xml вида: [data][name]tenshi[/name][name]PavelRadeev[/name][/data]

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

PavelRadaev 19 мая 2010 в 12:46

круто! да, на пхп не получится так «элегантно» добавить вывод ссылок на профили.

если не секрет, откуда у тебя xml берётся? генерится из данных пришедших из базы?