На прошлой недели запускал один проект и что-то мне не понравилась скорость генерации страниц. Начал искать в чём дело. Оказалось, в шаблонизаторе!
Думаю, очень многие разработчики используют в качестве шаблонизатора Smarty. По-моему, Smarty — самый известный шаблонный движок. Чем он знаменит?
- лёгок в освоении, понятен даже человеку, не владеющему PHP;
- легко интегрируется в готовые проекты;
- очень функционален, обладает практически своим языком программирования.
И вот тут-то «собака и зарыта». Программисты, использующие Smarty, пушат шаблоны на его (довольно корявом) языке, чтобы шаблонизатор потом постоянно перегонял эти шаблоны в php-код (куча никому не нужной работы!!!). Если вдуматься, получается самая большая глупость во всей истории программирования на PHP!
Не проще ли сразу писать шаблоны на PHP?
Какая разница писать: {$title} или <?php echo $title?> (либо <?=$title?>)? Да первый вариант, короче. Но это, скорее, дело привычки, а вот скорость приложений на «нативных» шаблонах вырастает в 2-3 раза! По-моему, неплохой результат и ради него можно написать пару-тройку лишних символов.
Два с лишним года я был ярым сторонником Smarty, но теперь я послал Smarty в пешее эротическое путешествие. Всё, теперь только «нативные» шаблоны: многие вещи в них сделать гораздо легче, чем в каких-либо других шаблонизаторах. Шаблонизатор уровня Smarty — это настоящие грабли!
Взамен 300-килобайтному Smarty, я за 10 минут написал свой простенький шаблонизатор. Его задача — собирать переменные в одно место и рендерить шаблоны. И всё! Больше от шаблонизатора ничего не нужно.
Итак, код:
<?php
class VIEW_View
{
private $_path;
private $_template;
private $_var = array();
public function __construct($path = '')
{
$this->_path = $_SERVER['DOCUMENT_ROOT'] . $path;
}
public function set($name, $value)
{
$this->_var[$name] = $value;
}
public function __get($name)
{
if (isset($this->_var[$name])) return $this->_var[$name];
return '';
}
public function display($template, $strip = true)
{
$this->_template = $this->_path . $template;
if (!file_exists($this->_template)) die('Шаблона ' . $this->_template . ' не существует!');
ob_start();
include($this->_template);
echo ($strip) ? $this->_strip(ob_get_clean()) : ob_get_clean();
}
private function _strip($data)
{
$lit = array("\\t", "\\n", "\\n\\r", "\\r\\n", " ");
$sp = array('', '', '', '', '');
return str_replace($lit, $sp, $data);
}
public function xss($data)
{
if (is_array($data)) {
$escaped = array();
foreach ($data as $key => $value) {
$escaped[$key] = $this->xss($value);
}
return $escaped;
}
return htmlspecialchars($data, ENT_QUOTES);
}
}
?>Вот и всё. Метод xss будет полезен при выводе данных для предотвращения XSS-уязвимости.
Пример использования:
<?php
require_once('class.view.php');
$view = new View('/tpl/');
$view->set('title', 'Наш заголовок');
$view->set('content', 'Какой-то текст.');
$view->display('index.tpl');
?>Файл шаблона /tpl/index.tpl
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1251" />
<title><?php echo $this->title?></title>
</head>
<body>
<h1><?php echo $this->title?></h1>
<?php echo $this->content?>
</body>
</html>По-моему, всё просто и удобно.
Замечение: «сложности» могут возникнуть с циклами foreach. Из-за бага в PHP. Данная ошибка уже исправлена в версиях PHP выше 5.0.5. Пользователям предыдущих версий просто придется писать:
forearch($t = $this->array as $k => $v)вместо:
forearch($this->array as $k => $v)Автор: Анатолий Ларин.
Комментарии:
Patrick
Ну если есть у клиента свой сервак или на худой конец VDS и еть потребность в шаблонизаторе, то Blitz. Хотя сам php является шаблонизатором :)
larin
Patrick
?, какая такая потребность? На фига?
Patrick
Толь, ты не всегда будешь разрабатывать проекты один и не всегда верстальщики буду знать php….
larin
Я найду такого, который знает. =)
Patrick
Не всегда будешь фрилансером ;)
larin
Конечно, не всегда. Когда-нить буду богатым фрилансером =)))
FX Poster
Мдя. Smarty хорош тем, что его шаблонный движок реально заточен под использование верстальщиками. :)
Пример: {$smarty.now|date_format:”%Y-%m-%d %H:%M:%S”}. Красиво, удобно.
По поводу своего View:
а почему не взять Zend_View? :)
public function set($name, $value)
{
$this->_var[$name] = $value;
}поменяй на __set
Я бы переменную класса $_template вообще убрал. Это View, ему пофиг что рендерить, название файла в нем содержаться не должно. Да и к тому же – у тебя эта переменная в одной функции юзается. Я бы переделал так:
public function display($template, $strip = true)
{
$template = $this->_path . $template;
if (!file_exists($template)) die(‘Шаблона ‘ . $template . ‘ не существует!’);
ob_start();
render($template);
echo ($strip) ? $this->_strip(ob_get_clean()) : ob_get_clean();
}
public function render()
{
include(func_get_args(0));
}
Зачем render делать – подумай на досуге. ;)
_strip можно бы было вынести в дополнительные плагины. Ну вообще – это я уже придираюсь. :) Посмотри на реализацию Zend_View на досуге.
FX Poster
Млин. Лучше бы оставил возможность свой html в комментах писать.
Patrick
__set, __get и другую магию я бы не использовал…
public function render()
{
extract($this->_vars);
ob_start();
include($this->_getTemplate());
$res = ob_get_contents();
ob_end_clean();
return $res;
}вот мой рендер…
А вообще неплохое разделения на дисплэй и рендер. Рендер по сути должен из щаблона, сделать Html(без вывода), например для Кэша всей страницы….
FX Poster
__set, __get и другую магию я бы не использовал…
И почему-же? )
На самом деле – с выводом рендер или без вывода – неважно. С ob_* всегда переделать можно.
Отдельную функцию для рендера делать можно и нужно чтобы полностью инкапсулировать тот файл, который мы include’им от локальных переменных.
public function display($template, $strip = true)
{
$this->_template = $this->_path . $template;
if (!file_exists($this->_template)) die('Шаблона ' . $this->_template . ' не существует!');
ob_start();
include($this->_template);
echo ($strip) ? $this->_strip(ob_get_clean()) : ob_get_clean();
}Здесь у нас в шаблоне будут доступны еще и переменные $template и $strip. Мелочь, но неприятно. ;)
Patrick
У тебя с темлейтами тот же бок. :) View и сами шаблоны находятся на разных уровнях программы. Хранить одно в другом – неправильно.
FX Poster
Да, и еще – по поводу смарти. Это же не только шаблонный движок. ;)
Hint: про кеширование в смарти почитай как-нить.
larin
FX Poster, ты думаешь я не читал, за 2-то года? =)))
Детские шалости все это, все равно он тормоз полный, и кэширование там слабенькое и неуклюжее.
larin
[offtop]Блин, достал этот WP! Мой вчерашний комментарий, просто исчез… у кого-нить такое было?[/offtop]
larin
FX Poster,
кажется твоя функция render() не подходит к моему примеру. Как я понял, данная функция не является методом класса VIEW_View, иначе введение не имеет смысла. Но при таком подходе функция render() ничего не знает о классе и мы получаем:
Fatal error: Using $this when not in object context in …/index.tpl on line 7
FX Poster
Как я понял, данная функция не является методом класса VIEW_View
Является ;)
larin
А смысл тогда??? В ней так же доступны все свойства класса. И никакой инкапсуляции…
FX Poster
Шаблон:
echo $template . ''; echo $strip . '';
Попробуй “выполнить” его в своем классе.
Я имею ввиду, что в твоем классе локальные переменные функции внутри шаблона также будут видны. А это плохо.
larin
Но у меня нет в шаблоне такого доступа. Все переменные в шаблоне у меня начинаются с $this.
Смысл, конечно есть, но ИМХО, не большой, т.к. это все рано не защитит нас от вызова свойств класса:
private $_path; private $_template; private $_var = array();
FX Poster
Я не знаю, может я плохой программер, но меня постоянно так и тянет написать переменную без $this. :)
По поводу
private $_path; private $_template; private $_var = array();Этого тоже можно избежать. Отнаследовавшись от твоего класса. В наследнике такой проблемы уже не будет.
larin
>>> Я не знаю, может я плохой программер, но меня постоянно так и тянет написать переменную без $this. :)
Нет, скорее ты ленивый программер.
>>> Этого тоже можно избежать. Отнаследовавшись от твоего класса. В наследнике такой проблемы уже не будет.
Точно! =) Ты прав, но мне как-то лень… на фик это. Я это делаю только для себя и пока для одного проекта. И в шаблоне мне явно не стукнет вызывать переменные начинающиеся с “_”.
А на счет наследования, верно. Класс View можно сделать абстрактным – абстрактным будет метод display() (+ можно добавить абстрактный метод fetch()), а от него уже наследовать классы: Html, Pdf, Rtf и т.д.
Patrick
View и сами шаблоны находятся на разных уровнях программы.
Поясни…
__set, __get и другую магию я бы не использовал…
И почему-же? )
вся эта магия только замедляет программу!
FX Poster
Patrick
Поясни…
Скажем так – считай View менеджером по работе с шаблонами. Ему пофиг, какой шаблон он будет обрабатывать. Он их все обрабатывает одинаково – следовательно хранить шаблон во View – неправильно.
Разные уровни программы – имеется ввиду, что понятие шаблон и вью напрямую не связаны. Client работает c View и Client работает с шаблоном (ну или с названием файла шаблона), и Client-же передает во View сам шаблон.
FX Poster
вся эта магия только замедляет программу!
Вот вы так говорите – долго, медленно, плохо. На самом деле обращения к той же бд будут занимать гораздо больше времени, чем php запустит функцию __get/__set. Я ни разу не встречал программы, в которой отказ от __get/__set или подобных функций (направленных на удобство программиста) реально сказывался на ее быстродействии. Т.е. если у тебя прога с такими функциями реально тупит, то и без них лучше не станет. Лучше ими пользоваться в полной мере, а в свободное время читать про реальные возможности рефакторинга. Благо – PHP такой [дебильный] язык, что тут можно рефакторить и рефакторить. Одно только различие в производительности $a[a] и $a['a'] чего стоит.
larin
>>> Я ни разу не встречал программы, в которой отказ от __get/__set или подобных функций (направленных на удобство программиста) реально сказывался на ее быстродействии.
FX Poster, зачет! Просто 5 баллов! Как говорится: экономия на спичках. Меня Patrick
не слушает, может к тебе прислушается =)
Patrick
Admin
Лень писать тесты… C include/require тебе пример привел…
FX Poster
Да нафиг тесты. Хочешь быстрее – юзай Си. Хочешь удобнее – юзай скриптовые языки. Юзать скриптовые языки и заморачиваться на синтаксисе (типа если мы напишем так – будет быстрее, чем если мы напишем по-другому) – в общем случае бред. Лучше позаморачиваться над хорошими алгоритмами. ;)
PS. В случае PHP – все же иногда позаморачиваться стоит – см. выше мой пример с индексами в массивах. Но в общем случае – это действительно бред.
FX Poster
Можешь мне не верить, но тебе это говорит человек, хорошо знающий C++ и умеющий оптимизировать программу не только с помощью оптимизаторов компилятора.
Sam
Неужели вы за 3 года не научились его правильно готовить?!
Как он может быть медленней, если шаблон не парсится каждый раз? Вы открывали когда-нибудь скомпилированные темплейты?
larin
Sam,
>>> Неужели вы за 3 года не научились его правильно готовить?!
Научился, и хорошо =) Но все же это костыли. Зачем писать на псевдоязыке, что б потом это все переводилось обратно в PHP? Это модно?
>>> Как он может быть медленней, если шаблон не парсится каждый раз? Вы открывали когда-нибудь скомпилированные темплейты?
Конечно смотрел…
Но я еще не только смотрел но и тестировал. Один и тот же проект я сделал и на Smarty и на своем шаблонизаторе – итог описан в этой статье.
То, что Smarty тормоз, я взял не с потолка, я это доказал на практике.
Sam
>>> В 2-3 раза
Это догадки, а не результаты тестов.
larin
Это не догадки, это реальные цифры.
Я их замерял.
На одной и той же машине. Один и тот же сайт. Один и тот же набор данных.
Так, что не нужно так заявлять.
Sam
Ну, обычно результаты тестов приводятся в миллисекундах. При этом тестирование должно проводится не разовым запуском, а как минимум apache bench или, как его ещё зовут, ab. Ну и, наверное, нет смысла говорить, что тестирование на страничках вроде “hello world” не в счёт т.к. не показывает ровным счётом ничего.
larin
Я тестировал при помощи ab. Правда, на Win-машине.
Я еще раз повторяю, что тестирование проходило на реальном сайте. Совсем не похожем на “hello world” =)))
Когда тестировал, я не собирался это никуда выкладывать… поэтому не сохранил данные из ab. Но я помню, что данные отличались в 2-3 раза.
Но если такой интерес есть, на днях я сделаю новые тесты и выложу данные в миллисекундах.
Sam
Будет очень интересно.
Patrick
Sam получите распешитесь ***
larin
Patrick, спасибо! =)
Тут данные уж совсем не в пользу Smarty, не в пользу аж в 4,5 раза!
CyberFox
Тема актуальная. Лично я использую Smarty, но предложенный код попробую. Может и у меня сообщения по этому поводу появятся.
larin
CyberFox
Попробуй.
И жду конструктивных комментариев =)
Sam
Спасибо. Поигрался. Жаль исходного кода теста нет :(
Выводы: при первой генерации шаблона Smarty действительно значительно отстаёт от нативных шаблонов, но обгоняет почти все остальные шаблонизаторы.
При повторном запуске Smarty занимает законное третье место:
1 php 0.000527 100%
2 php_templates 0.001863 354%
3 smarty 0.002531 480%
Не такое уж серьёзное отставание от php_templates, который, кстати, является pecl-расширением.
А если учесть что время генерации мало, пользователь будет ждать отнюдь не генерации страницы, а загрузки сгенерированной разметки.
DM
>Зачем писать на псевдоязыке, что б потом это все переводилось обратно в PHP? Это модно?
Ах да, нужно писать сразу в машинных кодах. Это модно.
Кеширование в смарти может сохранять шаблоны на смарти в шаблоны на РНР, в которые лучше не заглядывать. Оно работает? Работает. Работает быстро. Только в отличие от приведенного выше варианта работает процедурно а не объектно.
А кроме того можно еще поцепить опкодкешер и ZendOptimizer. И я не вижу разницы.
Sam
DM, это не кэширование, а компиляция. Кэширование там тоже есть.
DM
Да, пардон. Именно компиляцию имел ввиду.
larin
Sam,
>>> Спасибо. Поигрался. Жаль исходного кода теста нет :(
Таким образом, я думаю, могу не писать заново Smarty-шаблоны (т.к. после тестов они были удалены). Все и так ясно =)
To: all
Но даже при повторном запуске уже “откомпилированных” шаблонов Smarty проигрывает, и довольно сильно в скорости. Это видно из тестов и с этим согласился, наконец, Sam =)
To: DM
>>> Ах да, нужно писать сразу в машинных кодах. Это модно.
Зачем же так сразу… во всем нужно знать меру. :)
А кроме того можно еще поцепить опкодкешер и ZendOptimizer. И я не вижу разницы.
Не видите разницы? А если тоже самое сделать при нативных шаблонах? Не будет ли скорость больше?! :)
А вообще, я никого не собираюсь обращать в “свою веру”. Я думаю, каждый выбирает то, что ему более удобно и более полно подходит под определенную ситуацию. Скажу лишь, что Smarty не подходит для проектов с большой нагрузкой (хотя бы 300 000 хитов в сутки). Конечно можно поставить сервак мощнее, но стоит ли? Может проще для данного проекта отказаться от Smarty?
Sam
Но вы хоть согласны, что из всех построеных на php шаблонных движков Smarty является как самым быстрым, так и самым удобным?
DM
Насчет 300 000 хитов в сутки скоро проверим ;)
Сразу и ZendFramework с ним же =) Результаты у меня в блоге будут.
larin
Sam, конечно согласен!
Самым удобным, самым распространенным и самым быстрым (если брать движки написанные на PHP).
Я ж поэтому им и пользовался почти 3 года =)
DM, вы делаете крупный проект на ZF & Smarty?
Можно узнать на каком железе это будет работать и на какую нагрузку вы расчитываете?
Александр
Помойму на некотором этапе веб разработчик должен прозреть и понять, что процесс и скорость разработки/внедрения гораздо важнее, чем скорость шаблонизатора. тем более железо на сервере всегда можно наростить, а людского времени никогда не хватает и не поддается существенной прокачки.
Sam
Согласен. И особенно это актуально как раз для больших проектов. Тут важен баланс между удобством и производительностью. Как по мне – Smarty – золотая середина.
p.s. что ZF золотая середина сказать не могу…
larin
Александр, полностью с вами согласен. Но есть одно НО, мне все равно какие шаблоны писать Smarty || нативные… скорость разработки от этого не страдает.
Patrick
DM, судя то тестам ZF не самый быстрый Framework…. ИХМО я бы не стал его использовать в таких проектах…
Smarty является как самым быстрым
помоему WACT быстрее, да и больше функциональности у него…..
процесс и скорость разработки/внедрения гораздо важнее, чем скорость шаблонизатора
Переход на нативные шаблоны занимает час, с учётом написания класса
Александр
А сколько времени занимает обучение php дизайнера/верстальщика? А исравления ошибок за ними, поскольку сам шаблон на php дает большие возможности, а руки у творческих людей чешутся всегда?
Вообще если учесть специфику MVC, то шаблонизатор должен как можно меньше позволять. Только самые примитивные контсрукции. Языковые навороты для банальной презентации данных не нужны и опасны.
dkrnl
*** – Expose, a powerful PHP template engine.
движок на аснове pure-php, вообщем все хорошее уже придуманно.
Sam
€ 49 как-то не хочется за него отдавать.
larin
>>>А сколько времени занимает обучение php дизайнера/верстальщика?
А если сам программист занимается верской, что бывает кстати довольно часто? :)
>>> Вообще если учесть специфику MVC, то шаблонизатор должен как можно меньше позволять.
Думаю многие с вами не согласятся :)
larin
€ 49, за то, что можно написать за 15 мин?
А если там есть навороты, так они в движке не нужны ))
Patrick
А сколько времени занимает обучение php дизайнера/верстальщика? А исравления ошибок за ними, поскольку сам шаблон на php дает большие возможности, а руки у творческих людей чешутся всегда?
Отвечу вопросом на вопрос. А сколько на Smarty?????
Вообще если учесть специфику MVC, то шаблонизатор должен как можно меньше позволять.
наворотов в Smarty предостаточно… мне интересно причём тут шаблонизатор и MVC, разве Veiw переводится как шаблонизатор????
Sam
Если посмотреть внимательно, € 49 берут не за просто так.
Александр
А если сам программист занимается верской, что бывает кстати довольно часто? :
к счастью не всегда так:) но и программисты тоже люди.
Отвечу вопросом на вопрос. А сколько на Smarty?????
Меньше чем для php. Но хотелось бы ещё меньше.
наворотов в Smarty предостаточно… мне интересно причём тут шаблонизатор и MVC, разве Veiw переводится как шаблонизатор????
View подразумевает презентацию, она в конечном итоге осуществляется через тот или иной шаблонизатор.
larin
Александр,
>>>к счастью не всегда так:) но и программисты тоже люди.
Фраза, по-моему, подразумевает, что PHP-шаблоны намного сложнее Smarty-шаблонов… разве это так??? Да, программисты тоже люди (хотя и не всегда :) ) и при том ленивые люди (в большинстве), но какая разница писать: {$title} или <?php echo $title?> (либо <?=$title?>)?
Зато если нужна в шаблоне какая-то промежуточная переменная, не нужно громоздить конструкции типа:
{assign var=”name” value=”Bob”}, достаточно написать $name=’Bob’. Ведь программист тоже человек =)
Patrick
View подразумевает презентацию, она в конечном итоге осуществляется через тот или иной шаблонизатор.
Класса Анатолия(у меня кстати прмерно такой же), трудно назвать шаблонизатором….
Александр
Зато если нужна в шаблоне какая-то промежуточная переменная, не нужно громоздить конструкции типа:
php слишком много дает свободы. а от этого может пострадать разделение бизнес логики от представления
Класса Анатолия(у меня кстати прмерно такой же), трудно назвать шаблонизатором….
ну тогда давай называть шаблонизатором то, что соединяет данные и представление(html,pdf,xml,text и т.п.)
Patrick
Меньше чем для php. Но хотелось бы ещё меньше.
циклы, операторы вывода, присвоение переменных, ветвление, + ~20-30 функций намного быстрей выучить чем Smarty.
Александр
>>>циклы, операторы вывода, присвоение переменных, ветвление, + ~20-30 функций намного быстрей выучить чем Smarty.
если бы всё было так просто, то наверно шаблонизаторами никто и не пользовался.
Patrick
php слишком много дает свободы. а от этого может пострадать разделение бизнес логики от представления
свобода говорите? а теперь взглянем на Smarty.
{include_php}, {php} – это вообще жесть!, {fetch}, Модификаторы переменных, плагины. так что свободы в Smarty хоть отбавляй!
если бы всё было так просто, то наверно шаблонизаторами никто и не пользовался.
ну по крайней мере не сложней…
Александр
свобода говорите? а теперь взглянем на Smarty.
{include_php}, {php} – это вообще жесть!, {fetch}, Модификаторы переменных, плагины. так что свободы в Smarty хоть отбавляй!
Я Smarty не защищаю, а говорю вообще о проблеме шаблонизаторов. То что S дает хоть какую-то абстракцию уже хорошо.
larin
Александр, немного не понял вашу фразу: “…если бы всё было так просто, то наверно шаблонизаторами никто и не пользовался.”
Что вы имели в виду?
Я Smarty не защищаю…
А было похоже на то. :) :) :)
Смирнов Сергей
Спасибо большое за статью. Всегда знал, что Smarty несет в себе какое-то большое недоразумение:) Использую пассивные шаблонизаторы получается хорошо и без геморра.
Правда, у Smarty есть плюс: кеширование. Хотя, это как посмотреть…
Patrick
Правда, у Smarty есть плюс: кеширование. Хотя, это как посмотреть…
ИХМО кэширование должно проиходить не средствами шаблонизатора….Кэшироваться должны только “чистые” данные.
Банальный пример у тебя блок с html к кэше, закзчик поменял диз, кэш вернулся со старым html.
larin
Смирнов Сергей, пожалуйста.
В Smarty дохленькое кэширование, так что это не плюс.
Согласен с Patrick‘ом кэшировать нужно чистые данные, а не вывод. Это позволяет использовать кэширование более гибко и стоить системы которые не раздражают пользователей своими “зависаниями”. Для динамичных сайтов, где есть куча рейтингов, подсчет пользовательских баллов и.т. кеширование html-вывода не подойдет – оно просто не будет давать прироста в скорости.
Кирпичшн-Вунтру
Неужели, вы правда считаете, что прелесть смарти только в том чтобы забить переменные в массив, а затем их вывести? Если так, то мои соболезнования :)
larin
Кирпичшн-Вунтру, поделитесь с нами своими соображениями. Спасите наши умы =)
Я думаю, все с удовольствием выслушают, ваш рассказ о правильном использовании Smarty.
Артём Курапов
1.Синтаксис ?= (ёлки палки, у вас режутся обычные начала тэгов) хуже читается чем {
2.Кэширование данных у вас как я так понял отсутсвует
3.Архитектура MVC подразумевает что все данные во View попадают из Controller-а, а вы уверены что у вас не возникнет соблазна во view начать использовать глобальные переменные? Аналогично чёрная сторона в smarty использовать {php}.
4.Как тут уже говорили, что-бы движок стал реальным мало плюсов, надо что-бы им пользовались, тогда можно сотрудничать с другими разработчиками.
larin
Артём Курапов,
Артем, что вы имели в виду пож загадочной фразой: (ёлки палки, у вас режутся обычные начала тэгов)?
>>> Кэширование данных у вас как я так понял отсутсвует
Кэширование данных – это дело не шаблонизатора. Кэшированием у меня занимается отдельный модуль. Об этом я расскажу позднее.
По поводу 3-го пункта… какой-то он туманный, при чем здесь шаблонизатор? Здесь все зависит от вменяемости программиста.
По поводу четвертого: я никому не говорил, что мой класс – это реальный движок =), по моему, чтоб что-то было реальным: 1) Оно должно работать; 2) оно должно быть удобно тому программисту, который с этим работает.
Мне удобно в данное время работать с моим простеньким шаблонизатором. А от Smarty я отказался из-за его скорости (читайте выше), и для меня нет никакой разницы в удобстве чтения: {$title} или <?php echo $title?> (либо <?=$title?>)
Каждому свое… на вкус и цвет, все фломастеры разные. :)
LARIN » Архив блога » Скажи кэшированию… иногда :)
[...] я писал статью о Smaty, я не думал, что она вызовет столько внимания со [...]
Артём Курапов
Насчёт тэгов – поставил открывающий тэг php тут и комментарий обрезался дальше.. наверно его надо в html entity энкодить при показе, иначе он считается тэгом.. хотя я не эксперементировал.
Насчёт кэширования в принипе да, это надо делать отдельно, тем более если memcached есть и используется.
Про синтаксис это пожалуй самое главное. Я видел сайты написанные как сплошной php/html и даже с разделением логики на Controller-View (нечто типа theme в Joomla), впечатление было неприятное. Просто глаз не в состоянии быстро распознать хтмл тэги от пхп и приходится напрягаться просто что-бы понять где переменные а где оформление, я уж не говорю если замешаны вложенные if-else или циклы с объектами.
Smarty всё-таки ограничивает своим псевдо-языком возможности разработчика по использованию как сложных структур так и глобальных переменных. Всё что небыло передано напрямую через assign просто не существует. Эту чёткость потока данных я и имел ввиду под искушением использовать глобальные переменные.
Просто архитектура потока может быть древоподобной, либо как сеть, где всюду используется общие ресурсы – функции, переменные. И в последней архитектуре разбираться сложней новичку.
larin
Артём Курапов,
Насчёт тэгов – поставил открывающий тэг php тут и комментарий обрезался дальше.. наверно его надо в html entity энкодить при показе, иначе он считается тэгом.. хотя я не эксперементировал.
Странно. Хотя я тоже не экспериментировал – нет времени ))) Попробуйте конструкцию <pre><code>…</code></pre>
На счет того, что глазу сложно привыкнуть к синтаксису – так это зависит от редактора и от привычки. Всему нужно учиться и к некоторому нужно привыкнуть (кто-то привык к Windows, кто-то к Linux, а кому и MacOS душу греет :) )
В общем, я пришел к выводу, что каждый выбирает то, что ему больше нравиться и подходит для данной ситуации.
Я для себя выбор сделал. Поделился этим с вами, но я не заставляю вас идти по моему пути. Я просто показал еще одну тропинку, не мною открытую, но я по ней иду. :)
Как я уже говорил, Smarty “рулит” для клиентских приложений с небольшой нагрузкой, когда идет разделение труда программист-верстальщик.
Но для приложений где важна скорость, ИМХО, Smarty неповоротливый монстр. Без которого с легкостью можно обойтись.
cyberfox
Я тут посмотрел пример в действии (нашел наконец время 4:16 утра :) ) и меня это натолкнуло на мысль:
такой подход дает большую гибкость при построенни разного рода “движков”.
Если система документирована и входные/выходные данные и их форматы описаны и определены, то проблем особо не должно возникнуть для верстальщика шаблона.
Sam
Ну, это да…
larin
cyberfox, спасибо что нашел время, тем более такое оригинальное – 4 утра =)
А как ты смотрел его в действии? Применил в каком-то проекте?
cyberfox
Пока что нет, но возможно сайт Smolensk Linux User Group будет использовать эту фичу (но пока что он на Smarty).
Ближе к утру ознакомился с Zend Framework, наталкнуло на мысли, особенно когда нашел посто о сравнении производительности MCV фреймворков:
***
larin
На какие мысли?
Sam
Ну, какие тут могут быть мысли? Питон с Django делает всё и вся с большим отрывом и при этом довольно-таки стройный и продуманый.
На php, к сожалению, чем стройней, тем медленней. Внутренности CodeIgniter – это просто жесть, но работает он очень даже быстро, что наводит на мысль, что так и задумано…
Sylvio
в функции _strip забыты обратные слеши у спецсипмолов
larin
в функции _strip забыты обратные слеши у спецсипмолов
Ой, точно! И за столько комментов никто не заметил…
Они не забыты, это просто при вставке их WP порезал… Сейчас попробую поправить, хотя после такого количества пива не обещаю ))))
Sylvio, спасибо за внимательность! Поправил.
Яремчук Роман
Браво!- За замечательную статью.
larin
Яремчук Роман:
Браво!- За замечательную статью.
Спасибо. :))) Никак не ожидал столь высокой оценки ))
Да и такого количества комментариев не ожидал.
Sam
Главное – вовремя затеять спор ;)
larin
Sam:
Главное – вовремя затеять спор ;)
Я ж нечаянно. =)))
Кстати на счет спора. Интересный спор получился на тему кэширования. Присоединяйтесь пожалуйста, а то нам вдвоем с vasa_c довольно сложно подытожить тему.
bananos
Мда, начал читать и было подумал что автору наконец пришла в голову очевидная мысль, но после фразы
“за 10 минут написал свой простенький шаблонизатор” я разочаровался…
php сам по себе шаблонизатор, не надо изобретать велосипедов
larin
bananos
php сам по себе шаблонизатор, не надо изобретать велосипедов
=) А я разве говорил другое???? Вы не так поняли мою фразу: “за 10 минут написал свой простенький шаблонизатор”
Эта статья, как раз и была написана в защиту того, что PHP сам по себе прекрасный шаблонизатор.
Почитайте статью еще раз, а так же обратите внимание на комментарии
Patrick
“за 10 минут написал свой простенький шаблонизатор” я разочаровался…
В чём?
и что вы используете в качёстве View?
Sam
class VIEW_View :)
larin
Sam
class VIEW_View :)
В каком смысле? Вы используете в проектах мой VIEW_View? Или что? :)
bananos, куда вы пропали? Я по прежнему жду вашего ответа, на вопросы Patrick‘а.
Sam
Я про то, что все нормальные самописные шаблонизаторы похожи на class VIEW_View. Мой правда уже оброс неслабо… Layout-ы, хэлперы и т.д. Но смысл тот же.
Не думаю, что bananos придумал что-то очень уж отличающееся.
Patrick
Sam Хэлперы это из “другой” оперы…. Не думаю что лучшем решением будет напрямую включать их во View.
Sam
Почему же? Это довольно распросранённая и удобная практика. См. CakePHP, CodeIgniter.
Zend Framework: дорабатываем Zend_View
[...] очень похож на ряд велосипедов включая мой: HSTamplate, Прощай Smarty или простой шаблонизатор, Шаблонизировать за 6 секунд (и 6 строк) [...]
Stan
Может, я чё не то делаю, но при запуске тестовой странички из твоих примеров меня сразу выкидывают с грязными ругательствами: Parse error: parse error, unexpected T_STRING, expecting T_OLD_FUNCTION or T_FUNCTION or T_VAR or ‘}’ in z:\home\localhost\www\class.view.php on line 4
Не силен в php, что там ему не нравится во фразе private $_path; ? Может, у меня версия php не правильная?
Sam
Stan
У тебя случаем не PHP4?
Stan
Да, он самый – 4.4.4 кажись. В помойку? На пятый пора переходить?
Sam
Пора. Четвёрка официально больше не поддерживается.
Stan
У моего хостера тоже 4.4.4, облом :) Ладно, поставил я себе php5, запускаю – оппа! Что-то не нравится ему в строке $view = new View(‘/tpl/’); Говорит, что Fatal error: Class ‘View’ not found в этой строке. Может, опять что-то не хватает? :)
Sam
$view = new VIEW_View(’/tpl/’);
larin
@Sam, большое спасибо за помощь! =)))
@Stan, будь чуть внимательнее, а если, что пиши поможем. =)
Staglu
Не плохая сатья. Я в нете долго искал на подобие такой. Спасибо!!
Никита
Спасибо. Сразу после прочтения стал использовать вышеприведённый класс.
Но нашлось одно НО: информация внутри тэгов и выводится не так, как хотелось бы :(
Никита
Урс… Внутри тэгов: <pre> и <xmp>.
Sam
А как именно хочется и как выводится?
larin
Никита, приведите пожалуйста пример кода, при помощи которого “не так выводится информация”
Никита
ОК. Например, код
array ( [0] => ‘param’, … [n] => ‘param’ ), удобный для просмотра массивов, после передачи через $view->display(‘template’) становится таким:
Array ( [0] => ‘param’, … [n] => ‘param’ ), что не очень удобно для просмотра многомерных массивов.
Также через тоже удобно писать листинги кода и т.д. Но нужно иметь возможность сохранять предусмотренные отступы.
Никита
Блин!!!
В первом примере код такой:
Array(
[0] => ‘param’,
…
[n] => ‘param’
)
vasa_c
Какая разница писать: {$title} или (либо )?
Неоднократно поднимал подобный вопрос.
Наиболее распространенный ответ: “а вот разница”.
vasa_c
php-теги обрезались
larin
@vasa_c
И зачем смотреть на тех кто отвечает “а вот разница”.
По моему, они просто хотят похоливарить, и все )
Для вас есть разница писать:
{$title} или <?php echo $title?>?
З.Ы. Чтоб не резались php- и html-теги вставляйте их между тегами code
Daev
Первый вариант читабельней.
Sam
Так чуть читабельней:
Sam
Блин! Ненавижу этот WP :(
cyberfox
Что-то пост зарос камментами, видимо тема актуальная. Я после знакомства с CakePHP забыл что такое Smarty вообще.
larin
@cyberfox
Конечно, актуальная. Люди наконец начали осознавать, что PHP сам по себе очень мощный шаблонизатор.
И лучше использовать машинные ресурсы на что-либо другое, нежели на перевод с одного псевдоязыка на PHP.
И давно ты работаешь на CakePHP? Уже есть готовые проекты?
cyberfox
Нет, не давно, но успехи небольшие есть. Я нахожусь в данный момент в стадии познания технологии и попутно пеку сайт linux user group со старого движка.
Daev
Мне кажется, что ели уж экономить ресурсы, то надо начинать с отказа от самого php. А раз уж использовать его, то потери на шаблонизатор уже можно не учитывать.
larin
@Daev
Тоже вариант, но какой-то радикальный =)
В принципе, спор затянулся и спорить можно бесконечно, на некоторых проектах нативные шаблоны действительно дают выигрыш в производительности, на некоторых его не заметно.
Но, для себя я точно определил, что Сматри – это ненужный костыль, для PHP.
Сторонники Smarty, могут кидать в меня камни… а может кто-нить из них одумается… а может одумаюсь я =)))
Все может быть.
vasa_c
ping.
из дома ничего не доходит.
Меня забанили? )
larin
vasa_c, конечно нет!
Я рад активным комментаторам
SergiusD
А будет ли прирост производительности если передавать не копии а линки на переменные?
Конечно это добавит ограничения, но хотелось бы знать реальные цифры, стоит или нет.
public function set($name, &$value)
{
$this->_var[$name] = &$value;
}
vasa_c
SergiusD, неа.
***
SergiusD
Подскажите пожалуйста для чего нужна функция
private function _strip($data)
сначала думал что она убирает символы перевода строки и тп в шаблоне, то есть бесполезные с точки зрения html, но потом увидел что слеши экранированные. И зачем двойной пробел заменяеть на пустоту?
larin
SergiusD
Вы все правильно думали
Она убирает символы перевода строки во всех системах (Win, *nix, Mac), плюс убирает двойной пробел и табуляцию, т.к. эти символы так же не существенны для браузера.
Если парой слов – то это функция вытягивает весь HTML-код в одну строку.
Sam
Гм… нехорошо. Тогда уж убирать их только между > и <
larin
Кого их и почему?
Sam
Это я про _strip. Представь, что есть у нас тэг pre. Или же неразрывная строчка с 3-мя пробелами или ещё что…
larin
@Sam
Хм…
Верно! Это я упустил – косяк )
Кстати, у меня были на счет этого проблемы с JS-вставками, некоторые переставали работать при вытягивании в строку.
Может подскажешь как сделать аналог блока {literal}…{/literal} в Smarty. Т.е. что б тег между определенными тегами не вытягивался в строку.
Я понимаю, что это делается через регулярки, но как это сделать максимально красиво? Вот в чем вопрос.
Andrey
Максимально красиво с этим не заморачиваться!!!
SergiusD
@admin
Ну если уж убирать эти символы то в надо поправить в методе _strip 2 слэша на один слэш.. потому что она хочет менять сочетание символов \n а не сам перевод chr(10).
Если это сделано просто для экономии трафика то согласен с Andrey’ем что проще не мучаться, а использовать gzip-ование страниц перед отправкой
larin
@all
Если честно, сам эту функцию использовал всего пару раз =), а потом отказался от нее за ненадобностью. По-моему, сейчас уже нет насущной проблемы по экономии трафика.
vasa_c
Если уж продолжить домогаться до мелочей, то заменять переносы строк на пустоту некорректно. Две строки слипнутся в одну.
Да, и вы забыли одиночный \r. И, кстати, тогда последовательности \r\n \n\r не нужно указывать.
И в str_replace вторым аргументом можно указать просто “”.
И кроме PRE и SCRIPT, еще есть TEXTAREA и много чего.
+ Все атрибуты тегов.
+ Шаблонизатор не должен сам делать предположений, что нужно в верстке, а что нет.
+ У меня из дома не пишется, что это может быть?
:)
larin
@vasa_c
И в str_replace вторым аргументом можно указать просто “”.
Согласен.
+ Все атрибуты тегов.
+ Шаблонизатор не должен сам делать предположений, что нужно в верстке, а что нет.
Тоже согласен, поэтому этим методом и не пользуюсь =)))
+ У меня из дома не пишется, что это может быть?
А дома, случаем не спутниковый интернет?
vasa_c
Нет. Обычный.
Причем если послать второй раз то же сообщение пишет, что попытка дубля.
Sam
Я делал вот так:
$compressed = preg_replace("~>(\s+|\t+|\n+)<", $pagedata);
larin
@Sam
Ты кажется в функции preg_replace пропустил, один параметр.
А так идейка ничего, надо попробовать ))))
larin
Вот рабочий вариант, который удовлетворит все описанные выше требования
$compressed = preg_replace("@>(\s+|\t+|\n+)< @", '>< ', $html)
Это просто чуть исправленный пример Sam'а.
Sam
:)
Проверял?
Sam
У меня, кстати, просто строчку покоцал этот WP :(
larin
@Sam
Проверял?
Конечно, проверял. Даже в исходниках в своих заменил =)
Правда, я в исходниках добавил еще теги {literal}{/literal}
Между ними код вообще не обрабатывается. Это очень нужная вещь.
Sam
Мне пробел после < ужас как не нравится…
larin
@Sam
Мне тоже, но сделать с этим ничего не смог, это происки WP.
allatone
Спасибо за статью. А то я уж было подумал, что мне одному казалось, что Smarty – очень утлая замена php
AlexB
Постарался немного разобраться в данном вопросе.
http://pyha.ru/forum/topic/659
larin
@AlexB,
правда у вас там получился не разбор вопроса, а реклама шаблонизатора Blitz, ну да ладно =).
А вообще, по прошествии некоторого времени я понял, что вопрос выбора шаблонизатора – это скорее вопрос религии )
AlexB
Да нет, в общем, старался реально разобратся в вопросе и как-то упорядочить все.
Ну Blitz это да, пока ничего более удобного не попадалось. Но за рекламу мне не платили :) просто такие выводы у меня вышли.
larin
Ну я ж не говорю, что реклама коммерческая )))
Мне тоже Blitz понравился, правда, я еще не представилось случаю испробовать его на реальном проекте.
Знания, опыт, деньги.
[...] Прощай Smarty или простой шаблонизатор pdf [...]
Max
У меня возник вопрос касающийся статьи.
Объясню на примере форума. Есть список тем, тоесть один ряд который приходиться инклудить например 30 раз. Это нормально?
И второй вопрос про фигурные скобки.
$loadedTpl = file_get_contents($this->_template);
foreach ($this->_var as $key => $val){
$loadedTpl = str_replace(“{“. $key .”}”, $val, $loadedTpl);
}
и соответственно{title}
так плохо?
не судите строго, я начинающий :)
larin
@Max
Есть список тем, тоесть один ряд который приходиться инклудить например 30 раз. Это нормально?
Я немножко вас не понял… что значит инклудить 30 раз? Покажите пример кода.
А вообще итерации (повторения в теле цикла) это нормально.
$loadedTpl = file_get_contents($this->_template);
foreach ($this->_var as $key => $val){
$loadedTpl = str_replace(”{”. $key .”}”, $val, $loadedTpl);
}
и соответственно
{title}
так плохо?
Если проект не критичен к нагрузке, то нормально. Хотя, если нет критичности по скорости выполнения, то лучше использовать Smarty. В других, же случаях я предпочитаю использовать “нативные” (php) шаблоны. Либо же шаблонизатор WACT, но php-шаблоны, ИМХО, легче.
Max
Я немножко вас не понял… что значит инклудить 30 раз?
Есть повторяющийся html код, как например пост на форуме. Постов нужно вставить 30 штук, каждый раз подставляя переменные с другими значениями, т.е. нужен цикл, который, исходя из вашей статьи буедт 30 раз инклудить оидн и тот же файл. Вот тут и возникает вопрос про нагрузку.
Объясните пожалуйста из-за чего именно критичность. Из-за file_get_contents или str_replace. Т.к. в повторяющихся кусках кода file_get_contents() ипользуется только оидн раз, а далее идет только замена.
Я так понимаю с иклудом быстрее? Спасибо.
larin
@Max
Делайте просто include, и все будет хорошо.
Объясните пожалуйста из-за чего именно критичность. Из-за file_get_contents или str_replace.
Если проект небольшой (до 50 000 – 100 000 хитов), то ни в чем. А так str_replace не самая быстрая функция, хотя опять же это сказывается на больших объемах данных и при большом количестве итераций. Т.е. если шаблон у вас огромный и число итераций измеряется тысячами.
Прикол
Вы пишете:
>чтобы шаблонизатор потом постоянно перегонял эти
>шаблоны в PHP-код (куча никому не нужной работы!!!)
Smarty компилирует шаблон в php файл ОДИН раз, потом дергает этот php файл. Кроме того у него есть кеширование, которое если правильно организовать, дает очень неплохие результаты.
dLex
Кто то не доганяет для чего нужен шаблонизатор.
Чтобы пользователи которые имеют право на запись в шаблоны не имели доступа к php. (темы для блогов например) …
Roman
Лично я не навижу PHP перемешанный с HTML и независимо он того кто верстает страницы, дизайнер или программист, котлеты должны бить отдельно а мухи отдельно.
Сила смарти в том что он популярней всех остальных шаблонизаторов, и становится стандартом. Самая главная проблема всех PHP-шников и самый большой недостаток PHP, в том что нет четкой структуры как в яве.
Мне попадаются всякие сайты на доработку и иногда диву даешся какой может быть ламерский код, некоторые начинающие программисты умудряются почесать левой пяткой правое ухо. Реальный пример когда 1500 строчек дикого php кода, которого не в состоянии нормальный человек вникнуть вообще, первращается в 15 строчек и небольшой шаблончик. И самое плохое что большенство так и программирует изобретая велосипед, и тратя недели на то что можно сделать за час, а все потому что нет стандартов.
dLex
Так что Ларин =) учите мат.часть
dLex
Да а эту статью я лучше бы удалил =)
Andrey
dLex, смешно!!!!!
Roman, ну покажите мне шаблон на Java, точней на JSP.
larin
@dLex
Вы мне предлогаете учить мат. часть???
=) =) =) =) =) =) =) =) =)
dLex
Что смешного ? =)
не довать доступ к php
А статью удалил бы потому что класс написаный вами не возможно назвать шаблонизатором.
1 Я хочу сначала подгрузить шаблон №1 и выполнить парсер , но отдовать нечего пользователю не буду, потом шаблон №2 и №3
и только потом если все хорошо отдать пользователю =) html
2 ob_start(); ob_get_clean(); – у меня меня просто нет слов
3 $_SERVER['DOCUMENT_ROOT'] – отлично будет работать на IIS =)
dLex
ну как с твоим классом 1 вариант вкатит ?
dLex
Короче узай include($tmpl) =)
dLex
Короче это даже не велосипед =) тут колесо причем которое нельзя установить на велосипед =)
Так что Smarty учись настраивать и не грузить все его 300 кб =) и править
dLex
xml xslt – вот в чем сила брат
Sam
dLex
А что не так с ob_start(); ob_get_clean();?
cyberfox
Выскажусь по теме:
Раньше использовал Smarty, но как перешел на cakePHP
необходимость в нем отпала, как и в QuickForm.
Всегда считал, что PHP сам по себе шаблонизатор.
neyron-net
Всем доброго здравия.
В данный момент работаю программистом и верстальщиком, был во фрилансе почти 2 года…
Скажу лишь одну фразу. Smarty – остается Smarty, PHP – остается PHP…
Два колеса не могут крутиться в разных направлениях. Золотая середина появиться лишь тогда когда верстальщик будет знать и Smarty и PHP в равной степени, чтобы разбираться в коде. Ему еще нужно будет думать об кроссбраузерности и многих других вещах, нежели вести споры о “моде”.
____Из личного опыта_____
Всем спасибо. Ах. да. Пост…-Смарти – в топку. Все гениальное просто (Include).
NETMAN
Без нормального кеша твой шаблонизатор для смарти не конкурент.
larin
@NETMAN
Читай статьи дальше, там еще 2 статьи о кеше )))
Большое белечье ушко
последние несколько месяцев стал выносить всю логику из Smarty в php код, быстродействие немного увеличилось. В итоге шаблон содержит только циклы и выводы переменных. Отсюда вывод – для таких целей ну никак не требуется дополнительныё 150кб класс.
Кто видел в каком виде компилируются шаблоны Smarty? Этож полный ахтунг.
Кстати кеширование Smarty не всегда даёт прирост производительности, иногда наоборот замедление.
Циклы одно из узких мест в PHP, поэтому не рекомендую одни и те же данные гонять в разных циклах. Достаточно в одном цикле обработать их и тут же проверстать в блок шаблона.
Pawel W.
Smarty придуман, скорее, для сервисов, в качестве доступа аккаунтов к о*уенным серверным возможностям, чего и требуют аккаунты, но доступ, разумеется, в ограничительных рамках. И как иначе, ты, это сделаешь? Не давать же кому-угодно ковыряться в php-кодах всего сайта?
solo
полная херня написана
Maximus3
Smarty придуман, скорее, для сервисов, в качестве доступа аккаунтов к о*уенным серверным возможностям, чего и требуют аккаунты, но доступ, разумеется, в ограничительных рамках. И как иначе, ты, это сделаешь? Не давать же кому-угодно ковыряться в php-кодах всего сайта?
Это ж надо было такой бред сморозить…
Djinn
Здравствуйте… по моему шаблонизатор совсем не очень…
1) обязательно нужна функция fetch – ибо толку от шаблонизатора такого ?
2) зачем нужен шаблонизатор без кэширования ? можно просто инклудить шаблон, или ты это сделал чтобы переменные не смешивались ?
3) если программист не пишет в шаблоне $this – это большой плюс, а не лень! this вообще нет смысла писать так как ты используешь в шаблоне локальные переменные функции или класа + глобальные переменные, но я их не использую обычно…
Larin
@Djinn
Привет!
1) Функция fetch появилась на следующий день после написания статьи (добавлять было лень)). Я думаю, ее не сложно выделить из метода display, и чуток дописать )
2) Для удобства и структуризации )
3) В принципе, с этим согласен.
Вообще же в свете последнего перехода на Джанго… данный шаблонизатор просто позор на мои седины ) Хотя для того времени было нормально, главное он выполнял все поставленные перед ним задачи (правда, в несколько изменном виде)
Petr
Наткнулся на эту статью… Проблема по поводу шаблонизаторов появилась в начале 07 года. И только вот сейчас я встретил статью, в которой вполне ясно описано.
Какого вы мнения о FastTemplate ? Модная вещь была когда-то.
Вообще же в свете последнего перехода на Джанго… данный шаблонизатор просто позор на мои седины
Почему Django а не RoR ?
Petr
Сколько вам лет, гражданин программист,
и почему предложенный вами шаблонизатор (я б его пользовал только для “2) Для удобства и структуризации )”) спустя два года вы назвали позором.
Хочу его пользовать, так что интересно, что может быть в нём плохого.
Вы пока подумайте, а я скопирую его себе ))
Larin
@Petr
Какого вы мнения о FastTemplate ? Модная вещь была когда-то.
Модная, но не более. По мне Smarty намного лучше ) Но это конечно, субъективно.
Почему Django а не RoR ?
Красота и гибкость языка Python меня покорили ) Так же понравилась сама идеология Django.
Сколько вам лет, гражданин программист,
Об этом лучше умолчать ))))
и почему предложенный вами шаблонизатор (я б его пользовал только для “2) Для удобства и структуризации )”) спустя два года вы назвали позором.
Я постоянно учусь новому, развиваюсь и по новому смотрю на уже привычные вещи. И мой код, написанный, скажем 5 лет назад, иногда вызывает у меня улыбку, а иногда и ужас =)
Хочу его пользовать, так что интересно, что может быть в нём плохого.
Это скорее не шаблонизатор, а некий класс-хранилище )
Да и после Django не могу смотреть на шаблонизаторы без поддержки наследования шаблонов )
phpdude
Я делал вот так:
$compressed = preg_replace(“~>(\s+|\t+|\n+)<”, $pagedata);самое смешное, что это тоже смое, что и
$compressed = preg_replace(“#>(\s+)<”, $pagedata);)) ибо \s = [:space:]+\r+\n
MikJager
Я не обломался, все посты прочитал. Вы далеко не уходите от темы. О какой экономии Вы говорите, что значит в два три раза … что это, на 1 или 2 тысячные секунды смарти медленней, и что?! Что это … ужас какая нагрузка, или memory он много съел?! О чём вы говорите, о какой скорости …. конект к БД даёт такой тормоз всей системе, чтобы тысячные доли секунды смарти просто крошка от куска хлеба! Или кто то писал про ZendF … Вам вообще в этой теме делать нечего, тут битва за тысячные секунды, если Вы используете зенд, Вы не догадываетесь наверное, что такое нагрузка на сервак! По поводу нагрузке при нескольких десятков или сот тыс. хостов скажу вот что. Это явно не сайт визитка, наверняка кол-во запросов в БД будет там большое, да и обработка(вывод на том же нативном шаблонизаторе) будет довать существенный тормоз в скорости генерации страницы, один цикл в объемлемом данными массиве чего только стоит, уверен что это может даже не сотые секунды. Тут уже зависит от организации самого сервера! Я не спорь, верстаки не часто лезут что-то менять в шаблонах, но именно в момент создания он облегчает работу. Намного проще натягивать всё это дело.
Не скажу что это экономия на спичках (особенно с кэшированием, но в третий версии даже это было реализованно намного глаже), но это не то место где надо так сильно заботиться об экономии. Можно больше сэкономить на то, что правильно написать код php, более грамотно!
тест на win (средние значения из 100 проб на каждый) соответственно без кэширования!
ZF(db off) – 0.19
CI(db off) – 0.097
My(Db off) – 0.011
———————
ZF(db on) – 0.22
CI(db on) – 0.11
My(Db on) – 0.02
My – это Db Simple(dblab: убранна поддержка драйверов БД) и Smarty 3.
MikJager
ой … забыл не маловажное! И даже очень важное! Это memory!
ZF(db off) – 0.19 (7.8 мб)
CI(db off) – 0.097 (5.3 мб)
My(Db off) – 0.011 (780 кб)
———————
ZF(db on) – 0.22 (9.2 мб)
CI(db on) – 0.11 (6.1 мб)
My(Db on) – 0.02 (990 кб) ну ладно, путь будет 1 mb :)
По поводу оптимизации всегда будет много споров, использование кэширование(разного типа) и акселераторов. Очень много зависит как и от организации самой системы(программы) так и от сервера, и так же имеет фактор такой, как написание самого кода!
и или огого сколько
вот даже в такой сказалось ситуации можно выиграть огого сколько
Larin
Привет, Мик!
С момента написания статьи прошло более 2-х лет, и по прошествии этого времени я уже могу сказать – данный шаблонизатор не удобен ))) По правде говоря он вообще шаблонизатором не является, это просто класс-контейнер с данными и методами для работы с этими данными.
Но! На тот момент на одном из проектов данный подход действительно давал выигрыш и по времени, и по памяти.
Проект не использовал ни ZF, ни других сторонних FW. FW был свой, с минимумом слоев абстракции, максимально рассчитанный на быструю работу.
Но сейчас условия изменились и иногда бывает проще поставить еще один сервер, но работать с удобным шаблонизатором.
Опять же, все зависит от задачи!
MikJager
Ой пардон! дату поста не усмотрел) Конечно же, задачи и ставят определённые рамки в использование того или иного подхода(с тем же шаблонизатором). Просто если встречаются какие то недостатки или чего то не хватает, я думаю не трудно дополнить или изменить. В особенности со Smarty, у меня написаны множество модификаторов и функций, которые приводят выходящие данные к приятному виду. И с каждым проектом эти модификаторы постоянно пополняются. Просто объектно-ориентировочный подход уже даёт снижение производительности, но это снижение не ни что, по сравнению с тем, какие преимущества выходят при использование этого подхода. Smarty по моему мнению оптимальный вариант из ряда шаблонизаторов, который можно легко расширять под свои нужды(задачи) без особых проблем.
Хотелось бы чтобы те, кто не прочитал все комменты :) к посту, не сделали вывод, что Smarty это плохое решение. И не сказать что тут дело вкуса, скорее дело в правильной и обоснованной оценки при выборе того или иного решения.
Спасибо за пост Larin! Приятно было почитать всю эту дискуссию, хоть и времени ушло многовато :)
Larin
MikJager, пожалуйста!
Приятно, то мои посты приносят людям хоть какую-то пользу )
yura
Нормальный ман взял бы и написал….
а то ищете как поднять производительность….
какая нахрен производительность если всё методом тыка проверяется….
Levik
Мегадискуссия :)
В проектах, где к коду шаблонов должны иметь доступ “верстальщики” использование шаблонов считаю более-менее оправданным..
В основном же склоняюсь к php-”шаблонам” + при необходимости – кэшированию (естественно, разумному).
PS. спасибо автору за статью, всем комментаторам – за активное обсуждение :) Хотя, позиция некоторых мне мягко говоря не близка…
Larin
Приятно видеть, что при перепосте на других сайтах, дают ссылку на автора. =)
zlodeyev
SMARTY фуфло и говно засерающее код! Когда открываю проеты написаны на нем , будто в общественный туалет сходил. Только моск прованялся ибо пришлось разбираться в нем. SMARTY это для лохов типа я дизайнер и росту до программиста.
голый PHP это сила, организовать кеширование да и будет с Вами сила джадая, да и OOP редко когда себя оправдывает, господа.
Fghfghj
а сделать сайт который влазит в 1280 на 1024 слабо? даж читать не стал. надо думать о пользователях
coder
zlodeyev убейся ап стену, не знаешь ооп просто молчи