Комментарии 74
Использование тега {php} по умолчанию отключено и считается устаревшим.
Наконец-то!
— Автоматическое игнорирование фигурных скобок "{", "}", если они окружены пробелами (больше не требуется окружать Javascript {literal}{/literal} или использовать другой маркер тега).
Ад для верстальщиков с jQuery и вообще Javаsscript окончен. Ура товарищи! Ну и за lazyload огромное спасибо, в паре с предкомпиляцией и раздельным кешированием должно быть ооочень шустро.
Не думаю, что создавать javascript и css в html-шаблонах — хорошее занятие. Джаваскрипт должен быть ненавязчивым. Стили, в общем-то тоже ))
Так что это нововведение скорее деградация…
Lazyload для плагинов вроде как и во второй версии был…
Так что это нововведение скорее деградация…
Lazyload для плагинов вроде как и во второй версии был…
Деградация??
Да. Это как бы подталкивает: «Да да, мужики. Давайте, пишите свои js и css прямо в шаблонах».
Гораздо приятнее оформить js-код в виде плагина (jquery или любым другим способом, который по нраву). И подключать на события к элементам по классу или id (как обычно и делается).
Параметры можно передавать либо в, либо в свойствах элементов, на которые вешаются события… Тут уж по вкусу и цвету…
А так получается, что происходит разделение на MVC в бакенде, но во фронтэнде остается полная каша.
Это все ИМХО… Но как правило такая интеграция стилей и js в html до добра не доводит…
Гораздо приятнее оформить js-код в виде плагина (jquery или любым другим способом, который по нраву). И подключать на события к элементам по классу или id (как обычно и делается).
Параметры можно передавать либо в, либо в свойствах элементов, на которые вешаются события… Тут уж по вкусу и цвету…
А так получается, что происходит разделение на MVC в бакенде, но во фронтэнде остается полная каша.
Это все ИМХО… Но как правило такая интеграция стилей и js в html до добра не доводит…
Вообще-то, мне кажется, это называется не «деградация», а «совместимость». С какой стати разработчики Smarty должны диктовать свою волю верстальщикам? Конечно, удобно, когда весь JS во внешних файлах и ничего в HTML не мешает. А если что-то все же кому-то нужно вставить именно в шаблон?
Я не спорю, что это поможет новичкам быстрее освоить смарти. Но также и загонит их в ловушку турдукен-кода…
Впрочем вижу и положительную сторону этой медали. Будет проще вставить в шаблон великое многообразие счетчиков посещений )))
> С какой стати разработчики Smarty должны диктовать свою волю верстальщикам?
Нет, не должны… Они надеяться на сознательность ))) Которой у новичков нет…
> А если что-то все же кому-то нужно вставить именно в шаблон?
Тогда стоит пересмотреть архитектуру приложения )) И сделать немного по другому ))
Впрочем вижу и положительную сторону этой медали. Будет проще вставить в шаблон великое многообразие счетчиков посещений )))
> С какой стати разработчики Smarty должны диктовать свою волю верстальщикам?
Нет, не должны… Они надеяться на сознательность ))) Которой у новичков нет…
> А если что-то все же кому-то нужно вставить именно в шаблон?
Тогда стоит пересмотреть архитектуру приложения )) И сделать немного по другому ))
Авторы jQuery тоже турдукены? :_)
docs.jquery.com/How_jQuery_Works
Посмотрите исходник страницы
Посмотрите исходник страницы
Ахаха )))
И да, и нет )))
С одной стороны код действительно в коде страницы. С другой стороны так было делать совсем не обязательно ))) Этот код можно было бы вынести в отдельный файл и никто бы не потерял.
Возможно, что данное явление — лишь рабочий момент ))) Этот отрывок кода явно не для продакшена )))
Например:
//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();
});
И да, и нет )))
С одной стороны код действительно в коде страницы. С другой стороны так было делать совсем не обязательно ))) Этот код можно было бы вынести в отдельный файл и никто бы не потерял.
Возможно, что данное явление — лишь рабочий момент ))) Этот отрывок кода явно не для продакшена )))
Например:
//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/
Вы вообще по гуглу ходили? :)
— БОЖЕ!!! Это не ЗЕМЛЯ!!! Это планета ТУРДУКИЯ!!! МАААМАААА!!!
www.artlebedev.ru/
Вы вообще по гуглу ходили? :)
— БОЖЕ!!! Это не ЗЕМЛЯ!!! Это планета ТУРДУКИЯ!!! МАААМАААА!!!
Я искренне верю, что Артемий Лебедев занимается JS программингом ;) Особенно он пишет JS для своего сайта.
Могу привести пример, где интеграция JS и HTML дала обратный эффект. Скорость разработки выросла, понимание кода улучшилось, количество ошибок уменьшилось, код стал проще и понятнее. Нахождение ошибки не вызывает труда в любой промежуток времени, хоть через два года после создания функционала.
Что я делаю не так?
Что я делаю не так?
1. Сколько человек трудится над проектом? Ваш дизайнер понимает, что происходит в HTML?
2. Что, если нужно применить этот код на другой странице?
2. Что, если нужно применить этот код на другой странице?
1. Конкретно HTML занимаются 2 человека. Дизайнер понимает. Но при чем тут дизайнер?
2. Просто берите и используйте его.
2. Просто берите и используйте его.
1. Просто не все дизайнеры владеют Javascript-ом… Или они меня обманывали? )))
2. Я предпочитаю просто подключать нужный плагин… ;)
2. Я предпочитаю просто подключать нужный плагин… ;)
1. Дизайнеры вообще не обязаны владеть JS. Это прямая обязанность кодера.
2. Просто подключить плагин для интерфейсного решения не получится.
2. Просто подключить плагин для интерфейсного решения не получится.
1. Отлично, так а зачем же тогда заставлять дизайнера видеть этот JS-код? ИМХО, ни к чему…
2. Можно подключить JS-файл с дополнительным кодом, который и будет инициализировать плагин. Это можно делать где-нибудь в контроллере или команде. Возможно, добавлять еще какой-то функционал. Зато шаблон будет чистый.
И если человек, не разбирающийся в JS залезет в последующем в этот шаблон, ему будет проще разобраться. И больше вероятность, что он ничего не сломает ))
Для тех же целей и используется смарти. Для того же и запретили использовать {php}{/php}.
2. Можно подключить JS-файл с дополнительным кодом, который и будет инициализировать плагин. Это можно делать где-нибудь в контроллере или команде. Возможно, добавлять еще какой-то функционал. Зато шаблон будет чистый.
И если человек, не разбирающийся в JS залезет в последующем в этот шаблон, ему будет проще разобраться. И больше вероятность, что он ничего не сломает ))
Для тех же целей и используется смарти. Для того же и запретили использовать {php}{/php}.
php тег не запретили, а просто отключили по умолчанию. И я думаю, скорее из-за безопасности, чем для навязывания своей точки зрения.
1. Дизайнер то и HTML не должен видеть. Это не его задача.
2. Это теория. На практике все гораздо хуже. Тонны настроечных скриптов, вызовов функций, кода по сращиванию плагинов в единый функционал.
А теперь сделайте нормальный ненавязчивый JS для полностью AJAX-ового интерфейса :) Вы знаете такой продукт?
2. Это теория. На практике все гораздо хуже. Тонны настроечных скриптов, вызовов функций, кода по сращиванию плагинов в единый функционал.
А теперь сделайте нормальный ненавязчивый JS для полностью AJAX-ового интерфейса :) Вы знаете такой продукт?
* либо в <input type=«hidden» id=«my_key» value=«my_value» />
Ну, для избавления от ада использовался переход на другие указатели смати-тэгов, вместо одиночных фигурных скобок.
Или вынос основной части джаваскрипта во внешние файлы. Или упомянутый в статье {literal}, наконец, где «уже никак».
Или вынос основной части джаваскрипта во внешние файлы. Или упомянутый в статье {literal}, наконец, где «уже никак».
Бездумно заменить Smarty 2.6 на 3, всё-таки, у меня сегодня не вышло, на что-то ругалось.
Но нововведения не могут не радовать.
Но нововведения не могут не радовать.
Самое забавное что новые фичи убивают суть шаблонизатора — добавление функции, сложная математика.
А вот за наследование шаблонов спасибо авторам, молодцы.
А вот за наследование шаблонов спасибо авторам, молодцы.
Ни разу не придумал, как можно наследование использовать.
«функции» раньше заменялись многократным include file, например, в нутри итератора типа foreach или section.
Сложную математику, опять же, можно было писать и ранее с помощью math (если всё равно все исходные параметры передаются в шаблон, почему бы некую финальную величину и не посчитать уже прямо в шаблоне?)
Сложную математику, опять же, можно было писать и ранее с помощью math (если всё равно все исходные параметры передаются в шаблон, почему бы некую финальную величину и не посчитать уже прямо в шаблоне?)
Отделили представление от кода. Окончательно. Отделили. ппц.
а по-моему своего кучу налепили. минусуйте, но я считаю, что смарти это «компилятор условного кода в пхп на пхп». потому не понимаю его прелестей.
Я о том же. Только желчи больше.
Я согласен с Вами, мы не используем Smarty в новых проектах.
НО! Очень часто в жизни используются опенсорс разработки которые шаблонизируют как раз на Смарти, и те улучшения которые заявлены, действительно упрощают труд в первую очередь верстальщика, а уже потом интегратора.
НО! Очень часто в жизни используются опенсорс разработки которые шаблонизируют как раз на Смарти, и те улучшения которые заявлены, действительно упрощают труд в первую очередь верстальщика, а уже потом интегратора.
Шаблонизатор для шаблонизатора.
Оптимизацию по скорости делали? У меня на 50-ти килобайтном шаблоне третья версия бета примерно пятая или шестая тормозила раза в три-четыре по сравнению со второй версией.
Предугадывая вопросы отвечу.
Это уникальный шаблон, его переделать на много мелких файлов не получится.
Нет, содержимое не покажу.
Предугадывая вопросы отвечу.
Это уникальный шаблон, его переделать на много мелких файлов не получится.
Нет, содержимое не покажу.
Тормозила компиляция или отображение? Если компиляция, то это несущественно. Она ведь один раз всего выполняется и все, больше не нужна. Главное, чтобы отрисовка не тормозила.
Я смарти не первый год знаю.
Как раз все плохо с отрисовкой. Внутренние функции в третьем смарти компилируются в нечто невообразимое.
Как раз все плохо с отрисовкой. Внутренние функции в третьем смарти компилируются в нечто невообразимое.
Факты можно?
Можно, вот вам код, который делает компилятор Smarty2
Скорость 10000 итераций: ~0.014
Вот это делает Smarty3
Скорость выполнения: ~0.065
<?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
Да, еще, скорость работы функций смарти3 гораздо хуже примитивного defun/fun в смарти2. Это исправили, никто не знает?
Какой кошмар. Оно лагает еще больше.
Smarty всё больше соответствует «слогану» «PHP на PHP»
Продвинутый оператор ЯП Smarty ищет работу за еду.
Осталось реализовать eval и go to.
А зачем это нечто вааще нужно?
В реальном бизнес-процессе почему его кто-то может использовать?
Типа чтобы верстальщики не натворили бед? Ога, с тегом {php} походу не натворят :)
Плюс неужели есть реальные бизнес-кейсы где за косяки верстальщиков им люлей не отвешивают?
Хотя почитав www.smarty.net/best_practices начинаю понимать, что хотели товарищи изначально.
А по поводу тормозов — у кого они есть, попробуйте дебаг выключить и кэш включить.
В реальном бизнес-процессе почему его кто-то может использовать?
Типа чтобы верстальщики не натворили бед? Ога, с тегом {php} походу не натворят :)
Плюс неужели есть реальные бизнес-кейсы где за косяки верстальщиков им люлей не отвешивают?
Хотя почитав www.smarty.net/best_practices начинаю понимать, что хотели товарищи изначально.
А по поводу тормозов — у кого они есть, попробуйте дебаг выключить и кэш включить.
я так понимаю, что пост для тех, кто использует Smarty. а посему обращаюсь к тем, кто ругает этот шаблонизатор: почему бы Вам, уважаемые гении программирования, просто не пройти мимо. пост не про сравнительные характеристики технологий, но конкретно по новшествам конкретного шаблонизатора.
автору топика респект. сам бы я долго переводил и ползал по форуму Smarty в поисках примеров для лучшего понимания нововведений.
на самом деле новшеств больше, но автору удалось выделить основные моменты! особое спасибо за наследование и функции в шаблонах. теперь меньше кода, более гибче, читабильнее и быстрее, ибо кеширование отдельных элементов при правильном использовании!
и да! отдельное спасибо разработчикам за отсутствие экранов для javascript, признаюсь, очень свободно вздохнул!
автору топика респект. сам бы я долго переводил и ползал по форуму Smarty в поисках примеров для лучшего понимания нововведений.
на самом деле новшеств больше, но автору удалось выделить основные моменты! особое спасибо за наследование и функции в шаблонах. теперь меньше кода, более гибче, читабильнее и быстрее, ибо кеширование отдельных элементов при правильном использовании!
и да! отдельное спасибо разработчикам за отсутствие экранов для javascript, признаюсь, очень свободно вздохнул!
Теперь останется еще дождаться обновления SmartyPDT для Eclipse… :)
Отлично, многого давненько не хватало.
Ну не нравится мне смарти, мне кажется лишний этот «парсер». Мне почему-то больше Zend_View импонирует. Вот здорово было бы иметь шаблонизатор как в django, но чтобы он не на PHP был ;)
Очень неприятно осознавать, но Smarty ветки 2 отжирал на классе функций preg порядка 2000 вызовов и приложение (ориентированное на highload) теряло производительность на 28-35%. Вот такая грустная статистика…
А зачем приложение ориентированное на highload пользовалось шаблонизатором вообще или хотя бы Smarty в частности? Хоть бы blitz юзали тогда уже?
И еще вопрос — откуда там preg_*? Компиляция шаблонов? Тогда это странный highload, где шаблоны постоянно компилировались на сервере.
Возможно профилирование проводилось на не производственных серверах без скомпилированных шаблонов.
Спасибо за замечание. Попробую провести профилирование на скомпилированных шаблонах.
Спасибо за замечание. Попробую провести профилирование на скомпилированных шаблонах.
А я вдобавок советую проверить кэширование и откэшировать всю статику, какую только можно. Возможно это выльется в десяток display() вместо одного на страницу, но больше половины — с условным кэшированием, когда все время, кроме исхода времени жизни кэша, или сброса всего кэша, в статических блоках будет напрямую отдаваться готовая статика из файловой системы.
НЛО прилетело и опубликовало эту надпись здесь
А производительность как?
Smarty 2 работал до 4 раз медленнее, чем чистый PHP.
Как теперь дела с этим?
Smarty 2 работал до 4 раз медленнее, чем чистый PHP.
Как теперь дела с этим?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вышел Smarty 3 Final. Что нового?