Pull to refresh

Comments 74

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

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


Ад для верстальщиков с jQuery и вообще Javаsscript окончен. Ура товарищи! Ну и за lazyload огромное спасибо, в паре с предкомпиляцией и раздельным кешированием должно быть ооочень шустро.
Не думаю, что создавать javascript и css в html-шаблонах — хорошее занятие. Джаваскрипт должен быть ненавязчивым. Стили, в общем-то тоже ))

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

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

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

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

Это все ИМХО… Но как правило такая интеграция стилей и js в html до добра не доводит…
Вообще-то, мне кажется, это называется не «деградация», а «совместимость». С какой стати разработчики Smarty должны диктовать свою волю верстальщикам? Конечно, удобно, когда весь JS во внешних файлах и ничего в HTML не мешает. А если что-то все же кому-то нужно вставить именно в шаблон?
Я не спорю, что это поможет новичкам быстрее освоить смарти. Но также и загонит их в ловушку турдукен-кода…

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

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

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

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

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

И да, и нет )))

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

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

Например:

//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();
});
А Артемий Лебедев тоже турдукен? :)
www.artlebedev.ru/

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

— БОЖЕ!!! Это не ЗЕМЛЯ!!! Это планета ТУРДУКИЯ!!! МАААМАААА!!!
Я искренне верю, что Артемий Лебедев занимается JS программингом ;) Особенно он пишет JS для своего сайта.
Что действительно? Вы полагаете, ведущая российская студия дизайна набирает неграмотных дизайнеров, которые даже свой собственный сайт не могут нормально сделать? :)
Могу привести пример, где интеграция JS и HTML дала обратный эффект. Скорость разработки выросла, понимание кода улучшилось, количество ошибок уменьшилось, код стал проще и понятнее. Нахождение ошибки не вызывает труда в любой промежуток времени, хоть через два года после создания функционала.

Что я делаю не так?
1. Сколько человек трудится над проектом? Ваш дизайнер понимает, что происходит в HTML?
2. Что, если нужно применить этот код на другой странице?
1. Конкретно HTML занимаются 2 человека. Дизайнер понимает. Но при чем тут дизайнер?
2. Просто берите и используйте его.
1. Просто не все дизайнеры владеют Javascript-ом… Или они меня обманывали? )))
2. Я предпочитаю просто подключать нужный плагин… ;)
1. Дизайнеры вообще не обязаны владеть JS. Это прямая обязанность кодера.
2. Просто подключить плагин для интерфейсного решения не получится.
1. Отлично, так а зачем же тогда заставлять дизайнера видеть этот JS-код? ИМХО, ни к чему…

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

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

А теперь сделайте нормальный ненавязчивый JS для полностью AJAX-ового интерфейса :) Вы знаете такой продукт?
* либо в <input type=«hidden» id=«my_key» value=«my_value» />
Ну, для избавления от ада использовался переход на другие указатели смати-тэгов, вместо одиночных фигурных скобок.

Или вынос основной части джаваскрипта во внешние файлы. Или упомянутый в статье {literal}, наконец, где «уже никак».
Речь шла о смаРти-тэгах, конечно
Бездумно заменить Smarty 2.6 на 3, всё-таки, у меня сегодня не вышло, на что-то ругалось.
Но нововведения не могут не радовать.
Почитайте SMARTY2_BC_NOTES из дистрибутива. Наверняка, там найдется причина.
Самое забавное что новые фичи убивают суть шаблонизатора — добавление функции, сложная математика.

А вот за наследование шаблонов спасибо авторам, молодцы.
Ни разу не придумал, как можно наследование использовать.
а как без него вообще шаблонизатор использовать-то можно?)
Использовали же во второй версии.
«функции» раньше заменялись многократным include file, например, в нутри итератора типа foreach или section.

Сложную математику, опять же, можно было писать и ранее с помощью math (если всё равно все исходные параметры передаются в шаблон, почему бы некую финальную величину и не посчитать уже прямо в шаблоне?)
а по-моему своего кучу налепили. минусуйте, но я считаю, что смарти это «компилятор условного кода в пхп на пхп». потому не понимаю его прелестей.
Я о том же. Только желчи больше.
Я согласен с Вами, мы не используем Smarty в новых проектах.

НО! Очень часто в жизни используются опенсорс разработки которые шаблонизируют как раз на Смарти, и те улучшения которые заявлены, действительно упрощают труд в первую очередь верстальщика, а уже потом интегратора.
А что вы используете в новых проектах?
а почему не предоставить верстальщику нормальный апи рнр шаблонизатоора? и за 10 лет опыта веб разработок ни разу не сталкивался с верстальщиком, кто б не знал пыха. уж или уж можно запомнить… остальное все одинаковое.
Оптимизацию по скорости делали? У меня на 50-ти килобайтном шаблоне третья версия бета примерно пятая или шестая тормозила раза в три-четыре по сравнению со второй версией.

Предугадывая вопросы отвечу.
Это уникальный шаблон, его переделать на много мелких файлов не получится.
Нет, содержимое не покажу.
Тормозила компиляция или отображение? Если компиляция, то это несущественно. Она ведь один раз всего выполняется и все, больше не нужна. Главное, чтобы отрисовка не тормозила.
Я смарти не первый год знаю.
Как раз все плохо с отрисовкой. Внутренние функции в третьем смарти компилируются в нечто невообразимое.
Можно, вот вам код, который делает компилятор Smarty2
<?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)); ?>

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

Вот это делает Smarty3
<?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);?>


Скорость выполнения: ~0.065
Выложите на обменник, пожалуйста. Я бы глянул поближе.
ага и оригинальную .tpl пожалуйста
Да, еще, скорость работы функций смарти3 гораздо хуже примитивного defun/fun в смарти2. Это исправили, никто не знает?
Smarty всё больше соответствует «слогану» «PHP на PHP»
думаю, что этому слогану больше соответствует zend framework )) (хоть и не в тему)
а кто то же еще и смарти к зенду прикручивает =)))))))) однажды столкнулся :-D
Продвинутый оператор ЯП Smarty ищет работу за еду.
А зачем это нечто вааще нужно?

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

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

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

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

А по поводу тормозов — у кого они есть, попробуйте дебаг выключить и кэш включить.
я так понимаю, что пост для тех, кто использует Smarty. а посему обращаюсь к тем, кто ругает этот шаблонизатор: почему бы Вам, уважаемые гении программирования, просто не пройти мимо. пост не про сравнительные характеристики технологий, но конкретно по новшествам конкретного шаблонизатора.
автору топика респект. сам бы я долго переводил и ползал по форуму Smarty в поисках примеров для лучшего понимания нововведений.
на самом деле новшеств больше, но автору удалось выделить основные моменты! особое спасибо за наследование и функции в шаблонах. теперь меньше кода, более гибче, читабильнее и быстрее, ибо кеширование отдельных элементов при правильном использовании!
и да! отдельное спасибо разработчикам за отсутствие экранов для javascript, признаюсь, очень свободно вздохнул!
Качайте исходники и открывайте файл README, в нем все нововведения описаны.
Экраны решались просто: {{ }}
этого не знал. в мануале такого не нашёл. может мануал старый читал. спасибо за подсказку!
Ну дык надо просто переопределить left_delimiter и right_delimiter :)
Теперь останется еще дождаться обновления SmartyPDT для Eclipse… :)
Отлично, многого давненько не хватало.
Ну не нравится мне смарти, мне кажется лишний этот «парсер». Мне почему-то больше Zend_View импонирует. Вот здорово было бы иметь шаблонизатор как в django, но чтобы он не на PHP был ;)
есть аналог ninja — twig [twig-project.org]
Видел порт Django Templates на PHP но сам не пробовал https://github.com/speedmax/h2o-php
Очень неприятно осознавать, но Smarty ветки 2 отжирал на классе функций preg порядка 2000 вызовов и приложение (ориентированное на highload) теряло производительность на 28-35%. Вот такая грустная статистика…
А зачем приложение ориентированное на highload пользовалось шаблонизатором вообще или хотя бы Smarty в частности? Хоть бы blitz юзали тогда уже?
Смею предположить, что когда приложение только создавалось еще не было очевидно, что оно будет highload )))
И еще вопрос — откуда там preg_*? Компиляция шаблонов? Тогда это странный highload, где шаблоны постоянно компилировались на сервере.
Возможно профилирование проводилось на не производственных серверах без скомпилированных шаблонов.

Спасибо за замечание. Попробую провести профилирование на скомпилированных шаблонах.
А я вдобавок советую проверить кэширование и откэшировать всю статику, какую только можно. Возможно это выльется в десяток display() вместо одного на страницу, но больше половины — с условным кэшированием, когда все время, кроме исхода времени жизни кэша, или сброса всего кэша, в статических блоках будет напрямую отдаваться готовая статика из файловой системы.
UFO just landed and posted this here
А производительность как?
Smarty 2 работал до 4 раз медленнее, чем чистый PHP.
Как теперь дела с этим?
Sign up to leave a comment.

Articles