Вышел Smarty 3 Final. Что нового?

[@HighOctane]

Использование тега {php} по умолчанию отключено и считается устаревшим.

Наконец-то!

[@zoommy]

— Автоматическое игнорирование фигурных скобок "{", "}", если они окружены пробелами (больше не требуется окружать Javascript {literal}{/literal} или использовать другой маркер тега).

Ад для верстальщиков с jQuery и вообще Javаsscript окончен. Ура товарищи! Ну и за lazyload огромное спасибо, в паре с предкомпиляцией и раздельным кешированием должно быть ооочень шустро.

[@keltanas]

Не думаю, что создавать javascript и css в html-шаблонах — хорошее занятие. Джаваскрипт должен быть ненавязчивым. Стили, в общем-то тоже ))

Так что это нововведение скорее деградация…

Lazyload для плагинов вроде как и во второй версии был…

[@FractalizeR]

Деградация??

[@keltanas]

Да. Это как бы подталкивает: «Да да, мужики. Давайте, пишите свои js и css прямо в шаблонах».
Гораздо приятнее оформить js-код в виде плагина (jquery или любым другим способом, который по нраву). И подключать на события к элементам по классу или id (как обычно и делается).

Параметры можно передавать либо в, либо в свойствах элементов, на которые вешаются события… Тут уж по вкусу и цвету…

А так получается, что происходит разделение на MVC в бакенде, но во фронтэнде остается полная каша.

Это все ИМХО… Но как правило такая интеграция стилей и js в html до добра не доводит…

[@FractalizeR]

Вообще-то, мне кажется, это называется не «деградация», а «совместимость». С какой стати разработчики Smarty должны диктовать свою волю верстальщикам? Конечно, удобно, когда весь JS во внешних файлах и ничего в HTML не мешает. А если что-то все же кому-то нужно вставить именно в шаблон?

[@keltanas]

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

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

> С какой стати разработчики Smarty должны диктовать свою волю верстальщикам?

Нет, не должны… Они надеяться на сознательность ))) Которой у новичков нет…

> А если что-то все же кому-то нужно вставить именно в шаблон?

Тогда стоит пересмотреть архитектуру приложения )) И сделать немного по другому ))

[@FractalizeR]

Авторы jQuery тоже турдукены? :_)

[@FractalizeR]

docs.jquery.com/How_jQuery_Works
Посмотрите исходник страницы

[@keltanas]

Ахаха )))

И да, и нет )))

С одной стороны код действительно в коде страницы. С другой стороны так было делать совсем не обязательно ))) Этот код можно было бы вынести в отдельный файл и никто бы не потерял.

Возможно, что данное явление — лишь рабочий момент ))) Этот отрывок кода явно не для продакшена )))

Например:

//var items = [];
//source = source.replace(/\s*<(link|script).*?>\s\*/g, function(m){
//items.push(m);
//return "";
//}).replace("</head>", items.join("") + "</head>")
//*/

Или как Вам это?:

$(window).load(function(){
var doc = iframe.contentDocument || iframe.contentWindow.document;
source = source
.replace(/<script>([^<])/g,"<script>window.onload = (function(){\ntry{$1")
.replace(/([^>])<\/sc/g, '$1\n}catch(e){}});</sc');

source = source
.replace("</head>", "<style>html,body{border:0; margin:0; padding:0;}</style></head>");

doc.open();
doc.write( source );
doc.close();
});

[@FractalizeR]

А Артемий Лебедев тоже турдукен? :)
www.artlebedev.ru/

Вы вообще по гуглу ходили? :)

— БОЖЕ!!! Это не ЗЕМЛЯ!!! Это планета ТУРДУКИЯ!!! МАААМАААА!!!

[@keltanas]

Я искренне верю, что Артемий Лебедев занимается JS программингом ;) Особенно он пишет JS для своего сайта.

[@FractalizeR]

А причем тут это?

[@keltanas]

Действительно… ))

[@FractalizeR]

Что действительно? Вы полагаете, ведущая российская студия дизайна набирает неграмотных дизайнеров, которые даже свой собственный сайт не могут нормально сделать? :)

[@s0rr0w]

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

Что я делаю не так?

[@keltanas]

1. Сколько человек трудится над проектом? Ваш дизайнер понимает, что происходит в HTML?
2. Что, если нужно применить этот код на другой странице?

[@s0rr0w]

1. Конкретно HTML занимаются 2 человека. Дизайнер понимает. Но при чем тут дизайнер?
2. Просто берите и используйте его.

[@keltanas]

1. Просто не все дизайнеры владеют Javascript-ом… Или они меня обманывали? )))
2. Я предпочитаю просто подключать нужный плагин… ;)

[@s0rr0w]

1. Дизайнеры вообще не обязаны владеть JS. Это прямая обязанность кодера.
2. Просто подключить плагин для интерфейсного решения не получится.

[@keltanas]

1. Отлично, так а зачем же тогда заставлять дизайнера видеть этот JS-код? ИМХО, ни к чему…

2. Можно подключить JS-файл с дополнительным кодом, который и будет инициализировать плагин. Это можно делать где-нибудь в контроллере или команде. Возможно, добавлять еще какой-то функционал. Зато шаблон будет чистый.
И если человек, не разбирающийся в JS залезет в последующем в этот шаблон, ему будет проще разобраться. И больше вероятность, что он ничего не сломает ))

Для тех же целей и используется смарти. Для того же и запретили использовать {php}{/php}.

[@FractalizeR]

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

[@s0rr0w]

1. Дизайнер то и HTML не должен видеть. Это не его задача.
2. Это теория. На практике все гораздо хуже. Тонны настроечных скриптов, вызовов функций, кода по сращиванию плагинов в единый функционал.

А теперь сделайте нормальный ненавязчивый JS для полностью AJAX-ового интерфейса :) Вы знаете такой продукт?

[@keltanas]

* либо в <input type=«hidden» id=«my_key» value=«my_value» />

[@myem]

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

Или вынос основной части джаваскрипта во внешние файлы. Или упомянутый в статье {literal}, наконец, где «уже никак».

[@myem]

Речь шла о смаРти-тэгах, конечно

[@shattl]

Бездумно заменить Smarty 2.6 на 3, всё-таки, у меня сегодня не вышло, на что-то ругалось.
Но нововведения не могут не радовать.

[@FractalizeR]

Почитайте SMARTY2_BC_NOTES из дистрибутива. Наверняка, там найдется причина.

[@brook]

Самое забавное что новые фичи убивают суть шаблонизатора — добавление функции, сложная математика.

А вот за наследование шаблонов спасибо авторам, молодцы.

[@s0rr0w]

Ни разу не придумал, как можно наследование использовать.

[@kmike]

а как без него вообще шаблонизатор использовать-то можно?)

[@s0rr0w]

Использовали же во второй версии.

[@myem]

«функции» раньше заменялись многократным include file, например, в нутри итератора типа foreach или section.

Сложную математику, опять же, можно было писать и ранее с помощью math (если всё равно все исходные параметры передаются в шаблон, почему бы некую финальную величину и не посчитать уже прямо в шаблоне?)

[@redhummer]

Отделили представление от кода. Окончательно. Отделили. ппц.

[@MaXyC]

а по-моему своего кучу налепили. минусуйте, но я считаю, что смарти это «компилятор условного кода в пхп на пхп». потому не понимаю его прелестей.

[@redhummer]

Я о том же. Только желчи больше.

[@zoommy]

Я согласен с Вами, мы не используем Smarty в новых проектах.

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

[@FractalizeR]

А что вы используете в новых проектах?

[@Holden]

надеюсь XSLT?

[@MaXyC]

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

[@Veterinar]

Шаблонизатор для шаблонизатора.

[@s0rr0w]

Оптимизацию по скорости делали? У меня на 50-ти килобайтном шаблоне третья версия бета примерно пятая или шестая тормозила раза в три-четыре по сравнению со второй версией.

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

[@FractalizeR]

Тормозила компиляция или отображение? Если компиляция, то это несущественно. Она ведь один раз всего выполняется и все, больше не нужна. Главное, чтобы отрисовка не тормозила.

[@s0rr0w]

Я смарти не первый год знаю.
Как раз все плохо с отрисовкой. Внутренние функции в третьем смарти компилируются в нечто невообразимое.

[@FractalizeR]

Факты можно?

[@s0rr0w]

Можно, вот вам код, который делает компилятор Smarty2

<sub><?php /* Smarty version 2.6.26, created on 2010-11-16 14:48:36
compiled from index2.tpl */ ?>
<?php if (!function_exists('smarty_fun_foo')) { function smarty_fun_foo(&$smarty, $params) { $_fun_tpl_vars = $smarty->_tpl_vars; $smarty->assign($params); ?>
<?php if (! is_null ( $smarty->_tpl_vars['exec'] )): ?>
<?php $_from = $smarty->_tpl_vars['data']; if (!is_array($_from) && !is_object($_from)) { settype($_from, 'array'); }if (count($_from)):
foreach ($_from as $smarty->_tpl_vars['d']):
?>
<div><?php echo $smarty->_tpl_vars['d']; ?>
</div>
<?php endforeach; endif; unset($_from); ?>
<?php endif; ?>
<?php $smarty->_tpl_vars = $_fun_tpl_vars; }} smarty_fun_foo($this, array('exec'=>null)); ?>

<?php smarty_fun_foo($this, array('data'=>$this->_tpl_vars['data'],'exec'=>1)); ?></sub>

Скорость 10000 итераций: ~0.014

Вот это делает Smarty3

<sub><?php /* Smarty version Smarty-3.0.4, created on 2010-11-16 14:49:08
compiled from "./templates/index3.tpl" */ ?>
<?php /*%%SmartyHeaderCode:1315927594ce27dc484bdd9-24256128%%*/if(!defined('SMARTY_DIR')) exit('no direct access allowed');
$_smarty_tpl->decodeProperties(array (
'file_dependency' =>
array (
'bdf3642ce8219fafc40cbd62ea1ae69117a48c72' =>
array (
0 => './templates/index3.tpl',
1 => 1289907677,
2 => 'file',
),
),
'nocache_hash' => '1315927594ce27dc484bdd9-24256128',
'function' =>
array (
'foo' =>
array (
'parameter' =>
array (
'nocache' => false,
),
'compiled' => '
<?php $_smarty_tpl->tpl_vars[\'d\'] = new Smarty_Variable;
$_from = $_smarty_tpl->getVariable(\'data\')->value; if (!is_array($_from) && !is_object($_from)) { settype($_from, \'array\');}
if ($_smarty_tpl->_count($_from) > 0){
foreach ($_from as $_smarty_tpl->tpl_vars[\'d\']->key => $_smarty_tpl->tpl_vars[\'d\']->value){
?>
<div><?php echo (isset($_smarty_tpl->tpl_vars[\'d\']->value)? $_smarty_tpl->tpl_vars[\'d\']->value: null);?>
</div>
<?php }} ?>',
'nocache_hash' => '1315927594ce27dc484bdd9-24256128',
'has_nocache_code' => false,
),
),
'has_nocache_code' => 0,
)); /*/%%SmartyHeaderCode%%*/?>

<?php Smarty_Internal_Function_Call_Handler::call ('foo',$_smarty_tpl,array('data'=>$_smarty_tpl->getVariable('data')->value),'1315927594ce27dc484bdd9_24256128',false);?></sub>

Скорость выполнения: ~0.065

[@FractalizeR]

Выложите на обменник, пожалуйста. Я бы глянул поближе.

[@developer]

ага и оригинальную .tpl пожалуйста

[@s0rr0w]

Да, еще, скорость работы функций смарти3 гораздо хуже примитивного defun/fun в смарти2. Это исправили, никто не знает?

[@TravisBickle]

Какой кошмар. Оно лагает еще больше.

[@PQR]

Smarty всё больше соответствует «слогану» «PHP на PHP»

[@sarlv]

думаю, что этому слогану больше соответствует zend framework )) (хоть и не в тему)

[@MaXyC]

а кто то же еще и смарти к зенду прикручивает =)))))))) однажды столкнулся :-D

[@soltpain]

Продвинутый оператор ЯП Smarty ищет работу за еду.

[@docomo]

Осталось реализовать eval и go to.

[@garex]

А зачем это нечто вааще нужно?

В реальном бизнес-процессе почему его кто-то может использовать?

Типа чтобы верстальщики не натворили бед? Ога, с тегом {php} походу не натворят :)

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

Хотя почитав www.smarty.net/best_practices начинаю понимать, что хотели товарищи изначально.

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

[@Stepler]

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

[@s0rr0w]

Качайте исходники и открывайте файл README, в нем все нововведения описаны.

[@s0rr0w]

Экраны решались просто: {{ }}

[@Stepler]

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

[@s0rr0w]

Ну дык надо просто переопределить left_delimiter и right_delimiter :)

[@Vertex]

Теперь останется еще дождаться обновления SmartyPDT для Eclipse… :)

[@schursin]

Отлично, многого давненько не хватало.

[@iexx]

Ну не нравится мне смарти, мне кажется лишний этот «парсер». Мне почему-то больше Zend_View импонирует. Вот здорово было бы иметь шаблонизатор как в django, но чтобы он не на PHP был ;)

[@trevel]

есть аналог ninja — twig [twig-project.org]

[@seriyPS]

Видел порт Django Templates на PHP но сам не пробовал https://github.com/speedmax/h2o-php

[@vit1251]

Очень неприятно осознавать, но Smarty ветки 2 отжирал на классе функций preg порядка 2000 вызовов и приложение (ориентированное на highload) теряло производительность на 28-35%. Вот такая грустная статистика…

[@FractalizeR]

А зачем приложение ориентированное на highload пользовалось шаблонизатором вообще или хотя бы Smarty в частности? Хоть бы blitz юзали тогда уже?

[@vit1251]

Смею предположить, что когда приложение только создавалось еще не было очевидно, что оно будет highload )))

[@FractalizeR]

И еще вопрос — откуда там preg_*? Компиляция шаблонов? Тогда это странный highload, где шаблоны постоянно компилировались на сервере.

[@vit1251]

Возможно профилирование проводилось на не производственных серверах без скомпилированных шаблонов.

Спасибо за замечание. Попробую провести профилирование на скомпилированных шаблонах.

[@myem]

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

[@Trivium]

А производительность как?
Smarty 2 работал до 4 раз медленнее, чем чистый PHP.
Как теперь дела с этим?