На прошлой недели запускал один проект и что-то мне не понравилась скорость генерации страниц. Начал искать в чем дело. Оказалось, в шаблонизаторе!
Думаю, очень многие разработчики используют в качестве шаблонизатора 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)
Ну если есть у клиента свой сервак или на худой конец VDS и еть потребность в шаблонизаторе, то Blitz. Хотя сам php является шаблонизатором :)
Patrick?, какая такая потребность? На фига?
Толь, ты не всегда будешь разрабатывать проекты один и не всегда верстальщики буду знать php….
Я найду такого, который знает. =)
Не всегда будешь фрилансером ;)
Конечно, не всегда. Когда-нить буду богатым фрилансером =)))
Мдя. 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 на досуге.
Млин. Лучше бы оставил возможность свой html в комментах писать.
__set, __get и другую магию я бы не использовал…
public function render()
{
extract($this->_vars);
ob_start();
include($this->_getTemplate());
$res = ob_get_contents();
ob_end_clean();
return $res;
}
вот мой рендер…
А вообще неплохое разделения на дисплэй и рендер. Рендер по сути должен из щаблона, сделать Html(без вывода), например для Кэша всей страницы….
__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 и сами шаблоны находятся на разных уровнях программы. Хранить одно в другом - неправильно.
Да, и еще - по поводу смарти. Это же не только шаблонный движок. ;)
Hint: про кеширование в смарти почитай как-нить.
FX Poster, ты думаешь я не читал, за 2-то года? =)))
Детские шалости все это, все равно он тормоз полный, и кэширование там слабенькое и неуклюжее.
[offtop]Блин, достал этот WP! Мой вчерашний комментарий, просто исчез… у кого-нить такое было?[/offtop]
FX Poster,
кажется твоя функция render() не подходит к моему примеру. Как я понял, данная функция не является методом класса VIEW_View, иначе введение не имеет смысла. Но при таком подходе функция render() ничего не знает о классе и мы получаем:
Fatal error: Using $this when not in object context in …/index.tpl on line 7
Как я понял, данная функция не является методом класса VIEW_View
Является ;)
А смысл тогда??? В ней так же доступны все свойства класса. И никакой инкапсуляции…
Шаблон:
echo $template . '';echo $strip . '';
Попробуй “выполнить” его в своем классе.
Я имею ввиду, что в твоем классе локальные переменные функции внутри шаблона также будут видны. А это плохо.
Но у меня нет в шаблоне такого доступа. Все переменные в шаблоне у меня начинаются с $this.
Смысл, конечно есть, но ИМХО, не большой, т.к. это все рано не защитит нас от вызова свойств класса:
private $_path;
private $_template;
private $_var = array();
Я не знаю, может я плохой программер, но меня постоянно так и тянет написать переменную без $this. :)
По поводу
Этого тоже можно избежать. Отнаследовавшись от твоего класса. В наследнике такой проблемы уже не будет.
>>> Я не знаю, может я плохой программер, но меня постоянно так и тянет написать переменную без $this. :)
Нет, скорее ты ленивый программер.
>>> Этого тоже можно избежать. Отнаследовавшись от твоего класса. В наследнике такой проблемы уже не будет.
Точно! =) Ты прав, но мне как-то лень… на фик это. Я это делаю только для себя и пока для одного проекта. И в шаблоне мне явно не стукнет вызывать переменные начинающиеся с “_”.
А на счет наследования, верно. Класс View можно сделать абстрактным - абстрактным будет метод display() (+ можно добавить абстрактный метод fetch()), а от него уже наследовать классы: Html, Pdf, Rtf и т.д.
[i]View и сами шаблоны находятся на разных уровнях программы.[/i]
Поясни…
[i]__set, __get и другую магию я бы не использовал…
И почему-же? )[/i]
вся эта магия только замедляет программу!
Patrick
Поясни…
Скажем так - считай View менеджером по работе с шаблонами. Ему пофиг, какой шаблон он будет обрабатывать. Он их все обрабатывает одинаково - следовательно хранить шаблон во View - неправильно.
Разные уровни программы - имеется ввиду, что понятие шаблон и вью напрямую не связаны. Client работает c View и Client работает с шаблоном (ну или с названием файла шаблона), и Client-же передает во View сам шаблон.
вся эта магия только замедляет программу!
Вот вы так говорите - долго, медленно, плохо. На самом деле обращения к той же бд будут занимать гораздо больше времени, чем php запустит функцию __get/__set. Я ни разу не встречал программы, в которой отказ от __get/__set или подобных функций (направленных на удобство программиста) реально сказывался на ее быстродействии. Т.е. если у тебя прога с такими функциями реально тупит, то и без них лучше не станет. Лучше ими пользоваться в полной мере, а в свободное время читать про реальные возможности рефакторинга. Благо - PHP такой [дебильный] язык, что тут можно рефакторить и рефакторить. Одно только различие в производительности $a[a] и $a['a'] чего стоит.
>>> Я ни разу не встречал программы, в которой отказ от __get/__set или подобных функций (направленных на удобство программиста) реально сказывался на ее быстродействии.
FX Poster, зачет! Просто 5 баллов! Как говорится: экономия на спичках. Меня Patrick не слушает, может к тебе прислушается =)
Admin
Лень писать тесты… C include/require тебе пример привел…
Да нафиг тесты. Хочешь быстрее - юзай Си. Хочешь удобнее - юзай скриптовые языки. Юзать скриптовые языки и заморачиваться на синтаксисе (типа если мы напишем так - будет быстрее, чем если мы напишем по-другому) - в общем случае бред. Лучше позаморачиваться над хорошими алгоритмами. ;)
PS. В случае PHP - все же иногда позаморачиваться стоит - см. выше мой пример с индексами в массивах. Но в общем случае - это действительно бред.
Можешь мне не верить, но тебе это говорит человек, хорошо знающий C++ и умеющий оптимизировать программу не только с помощью оптимизаторов компилятора.
Неужели вы за 3 года не научились его правильно готовить?!
Как он может быть медленней, если шаблон не парсится каждый раз? Вы открывали когда-нибудь скомпилированные темплейты?
Sam,
>>> Неужели вы за 3 года не научились его правильно готовить?!
Научился, и хорошо =) Но все же это костыли. Зачем писать на псевдоязыке, что б потом это все переводилось обратно в PHP? Это модно?
>>> Как он может быть медленней, если шаблон не парсится каждый раз? Вы открывали когда-нибудь скомпилированные темплейты?
Конечно смотрел…
Но я еще не только смотрел но и тестировал. Один и тот же проект я сделал и на Smarty и на своем шаблонизаторе - итог описан в этой статье.
То, что Smarty тормоз, я взял не с потолка, я это доказал на практике.
>>> В 2-3 раза
Это догадки, а не результаты тестов.
Это не догадки, это реальные цифры.
Я их замерял.
На одной и той же машине. Один и тот же сайт. Один и тот же набор данных.
Так, что не нужно так заявлять.
Ну, обычно результаты тестов приводятся в миллисекундах. При этом тестирование должно проводится не разовым запуском, а как минимум apache bench или, как его ещё зовут, ab. Ну и, наверное, нет смысла говорить, что тестирование на страничках вроде “hello world” не в счёт т.к. не показывает ровным счётом ничего.
Я тестировал при помощи ab. Правда, на Win-машине.
Я еще раз повторяю, что тестирование проходило на реальном сайте. Совсем не похожем на “hello world” =)))
Когда тестировал, я не собирался это никуда выкладывать… поэтому не сохранил данные из ab. Но я помню, что данные отличались в 2-3 раза.
Но если такой интерес есть, на днях я сделаю новые тесты и выложу данные в миллисекундах.
Будет очень интересно.
Sam получите распешитесь http://test.country-info.ru/bench/?block_count=50&text_length=1000&var_count=9&iterations=5&12=on&3=on
Patrick, спасибо! =)
Тут данные уж совсем не в пользу Smarty, не в пользу аж в 4,5 раза!
Тема актуальная. Лично я использую Smarty, но предложенный код попробую. Может и у меня сообщения по этому поводу появятся.
CyberFox
Попробуй.
И жду конструктивных комментариев =)
Спасибо. Поигрался. Жаль исходного кода теста нет :(
Выводы: при первой генерации шаблона Smarty действительно значительно отстаёт от нативных шаблонов, но обгоняет почти все остальные шаблонизаторы.
При повторном запуске Smarty занимает законное третье место:
1 php 0.000527 100%
2 php_templates 0.001863 354%
3 smarty 0.002531 480%
Не такое уж серьёзное отставание от php_templates, который, кстати, является pecl-расширением.
А если учесть что время генерации мало, пользователь будет ждать отнюдь не генерации страницы, а загрузки сгенерированной разметки.
>Зачем писать на псевдоязыке, что б потом это все переводилось обратно в PHP? Это модно?
Ах да, нужно писать сразу в машинных кодах. Это модно.
Кеширование в смарти может сохранять шаблоны на смарти в шаблоны на РНР, в которые лучше не заглядывать. Оно работает? Работает. Работает быстро. Только в отличие от приведенного выше варианта работает процедурно а не объектно.
А кроме того можно еще поцепить опкодкешер и ZendOptimizer. И я не вижу разницы.
DM, это не кэширование, а компиляция. Кэширование там тоже есть.
Да, пардон. Именно компиляцию имел ввиду.
Sam,
>>> Спасибо. Поигрался. Жаль исходного кода теста нет :(
Таким образом, я думаю, могу не писать заново Smarty-шаблоны (т.к. после тестов они были удалены). Все и так ясно =)
To: all
Но даже при повторном запуске уже “откомпилированных” шаблонов Smarty проигрывает, и довольно сильно в скорости. Это видно из тестов и с этим согласился, наконец, Sam =)
To: DM
>>> Ах да, нужно писать сразу в машинных кодах. Это модно.
Зачем же так сразу… во всем нужно знать меру. :)
А кроме того можно еще поцепить опкодкешер и ZendOptimizer. И я не вижу разницы.
Не видите разницы? А если тоже самое сделать при нативных шаблонах? Не будет ли скорость больше?! :)
А вообще, я никого не собираюсь обращать в “свою веру”. Я думаю, каждый выбирает то, что ему более удобно и более полно подходит под определенную ситуацию. Скажу лишь, что Smarty не подходит для проектов с большой нагрузкой (хотя бы 300 000 хитов в сутки). Конечно можно поставить сервак мощнее, но стоит ли? Может проще для данного проекта отказаться от Smarty?
Но вы хоть согласны, что из всех построеных на php шаблонных движков Smarty является как самым быстрым, так и самым удобным?
Насчет 300 000 хитов в сутки скоро проверим ;)
Сразу и ZendFramework с ним же =) Результаты у меня в блоге будут.
Sam, конечно согласен!
Самым удобным, самым распространенным и самым быстрым (если брать движки написанные на PHP).
Я ж поэтому им и пользовался почти 3 года =)
DM, вы делаете крупный проект на ZF & Smarty?
Можно узнать на каком железе это будет работать и на какую нагрузку вы расчитываете?
Помойму на некотором этапе веб разработчик должен прозреть и понять, что процесс и скорость разработки/внедрения гораздо важнее, чем скорость шаблонизатора. тем более железо на сервере всегда можно наростить, а людского времени никогда не хватает и не поддается существенной прокачки.
Согласен. И особенно это актуально как раз для больших проектов. Тут важен баланс между удобством и производительностью. Как по мне - Smarty - золотая середина.
p.s. что ZF золотая середина сказать не могу…
Александр, полностью с вами согласен. Но есть одно НО, мне все равно какие шаблоны писать Smarty || нативные… скорость разработки от этого не страдает.
DM, судя то тестам ZF не самый быстрый Framework…. ИХМО я бы не стал его использовать в таких проектах…
Smarty является как самым быстрым
помоему WACT быстрее, да и больше функциональности у него…..
процесс и скорость разработки/внедрения гораздо важнее, чем скорость шаблонизатора
Переход на нативные шаблоны занимает час, с учётом написания класса
А сколько времени занимает обучение php дизайнера/верстальщика? А исравления ошибок за ними, поскольку сам шаблон на php дает большие возможности, а руки у творческих людей чешутся всегда?
Вообще если учесть специфику MVC, то шаблонизатор должен как можно меньше позволять. Только самые примитивные контсрукции. Языковые навороты для банальной презентации данных не нужны и опасны.
http://www.kwasd.nl/expose/ - Expose, a powerful PHP template engine.
движок на аснове pure-php, вообщем все хорошее уже придуманно.
€ 49 как-то не хочется за него отдавать.
>>>А сколько времени занимает обучение php дизайнера/верстальщика?
А если сам программист занимается верской, что бывает кстати довольно часто? :)
>>> Вообще если учесть специфику MVC, то шаблонизатор должен как можно меньше позволять.
Думаю многие с вами не согласятся :)
€ 49, за то, что можно написать за 15 мин?
А если там есть навороты, так они в движке не нужны ))
А сколько времени занимает обучение php дизайнера/верстальщика? А исравления ошибок за ними, поскольку сам шаблон на php дает большие возможности, а руки у творческих людей чешутся всегда?
Отвечу вопросом на вопрос. А сколько на Smarty?????
Вообще если учесть специфику MVC, то шаблонизатор должен как можно меньше позволять.
наворотов в Smarty предостаточно… мне интересно причём тут шаблонизатор и MVC, разве Veiw переводится как шаблонизатор????
Если посмотреть внимательно, € 49 берут не за просто так.
А если сам программист занимается верской, что бывает кстати довольно часто? :
к счастью не всегда так:) но и программисты тоже люди.
Отвечу вопросом на вопрос. А сколько на Smarty?????
Меньше чем для php. Но хотелось бы ещё меньше.
наворотов в Smarty предостаточно… мне интересно причём тут шаблонизатор и MVC, разве Veiw переводится как шаблонизатор????
View подразумевает презентацию, она в конечном итоге осуществляется через тот или иной шаблонизатор.
Александр,
>>>к счастью не всегда так:) но и программисты тоже люди.
Фраза, по-моему, подразумевает, что PHP-шаблоны намного сложнее Smarty-шаблонов… разве это так??? Да, программисты тоже люди (хотя и не всегда :) ) и при том ленивые люди (в большинстве), но какая разница писать: {$title} или < ?php echo $title?> (либо < ?=$title?>)?
Зато если нужна в шаблоне какая-то промежуточная переменная, не нужно громоздить конструкции типа:
{assign var=”name” value=”Bob”}, достаточно написать $name=’Bob’. Ведь программист тоже человек =)
View подразумевает презентацию, она в конечном итоге осуществляется через тот или иной шаблонизатор.
Класса Анатолия(у меня кстати прмерно такой же), трудно назвать шаблонизатором….
Зато если нужна в шаблоне какая-то промежуточная переменная, не нужно громоздить конструкции типа:
php слишком много дает свободы. а от этого может пострадать разделение бизнес логики от представления
Класса Анатолия(у меня кстати прмерно такой же), трудно назвать шаблонизатором….
ну тогда давай называть шаблонизатором то, что соединяет данные и представление(html,pdf,xml,text и т.п.)
Меньше чем для php. Но хотелось бы ещё меньше.
циклы, операторы вывода, присвоение переменных, ветвление, + ~20-30 функций намного быстрей выучить чем Smarty.
>>>циклы, операторы вывода, присвоение переменных, ветвление, + ~20-30 функций намного быстрей выучить чем Smarty.
если бы всё было так просто, то наверно шаблонизаторами никто и не пользовался.
php слишком много дает свободы. а от этого может пострадать разделение бизнес логики от представления
свобода говорите? а теперь взглянем на Smarty.
{include_php}, {php} - это вообще жесть!, {fetch}, Модификаторы переменных, плагины. так что свободы в Smarty хоть отбавляй!
если бы всё было так просто, то наверно шаблонизаторами никто и не пользовался.
ну по крайней мере не сложней…
свобода говорите? а теперь взглянем на Smarty.
{include_php}, {php} - это вообще жесть!, {fetch}, Модификаторы переменных, плагины. так что свободы в Smarty хоть отбавляй!
Я Smarty не защищаю, а говорю вообще о проблеме шаблонизаторов. То что S дает хоть какую-то абстракцию уже хорошо.
Александр, немного не понял вашу фразу: “…если бы всё было так просто, то наверно шаблонизаторами никто и не пользовался.”
Что вы имели в виду?
Я Smarty не защищаю…
А было похоже на то. :) :) :)
Спасибо большое за статью. Всегда знал, что Smarty несет в себе какое-то большое недоразумение:) Использую пассивные шаблонизаторы получается хорошо и без геморра.
Правда, у Smarty есть плюс: кеширование. Хотя, это как посмотреть…
Правда, у Smarty есть плюс: кеширование. Хотя, это как посмотреть…
ИХМО кэширование должно проиходить не средствами шаблонизатора….Кэшироваться должны только “чистые” данные.
Банальный пример у тебя блок с html к кэше, закзчик поменял диз, кэш вернулся со старым html.
Смирнов Сергей, пожалуйста.
В Smarty дохленькое кэширование, так что это не плюс.
Согласен с Patrick‘ом кэшировать нужно чистые данные, а не вывод. Это позволяет использовать кэширование более гибко и стоить системы которые не раздражают пользователей своими “зависаниями”. Для динамичных сайтов, где есть куча рейтингов, подсчет пользовательских баллов и.т. кеширование html-вывода не подойдет - оно просто не будет давать прироста в скорости.
Неужели, вы правда считаете, что прелесть смарти только в том чтобы забить переменные в массив, а затем их вывести? Если так, то мои соболезнования :)
Кирпичшн-Вунтру, поделитесь с нами своими соображениями. Спасите наши умы =)
Я думаю, все с удовольствием выслушают, ваш рассказ о правильном использовании Smarty.
1.Синтаксис ?= (ёлки палки, у вас режутся обычные начала тэгов) хуже читается чем {
2.Кэширование данных у вас как я так понял отсутсвует
3.Архитектура MVC подразумевает что все данные во View попадают из Controller-а, а вы уверены что у вас не возникнет соблазна во view начать использовать глобальные переменные? Аналогично чёрная сторона в smarty использовать {php}.
4.Как тут уже говорили, что-бы движок стал реальным мало плюсов, надо что-бы им пользовались, тогда можно сотрудничать с другими разработчиками.
Артём Курапов,
Артем, что вы имели в виду пож загадочной фразой: (ёлки палки, у вас режутся обычные начала тэгов)?
>>> Кэширование данных у вас как я так понял отсутсвует
Кэширование данных - это дело не шаблонизатора. Кэшированием у меня занимается отдельный модуль. Об этом я расскажу позднее.
По поводу 3-го пункта… какой-то он туманный, при чем здесь шаблонизатор? Здесь все зависит от вменяемости программиста.
По поводу четвертого: я никому не говорил, что мой класс - это реальный движок =), по моему, чтоб что-то было реальным: 1) Оно должно работать; 2) оно должно быть удобно тому программисту, который с этим работает.
Мне удобно в данное время работать с моим простеньким шаблонизатором. А от Smarty я отказался из-за его скорости (читайте выше), и для меня нет никакой разницы в удобстве чтения: {$title} или < ?php echo $title?> (либо < ?=$title?>)
Каждому свое… на вкус и цвет, все фломастеры разные. :)
[...] я писал статью о Smaty, я не думал, что она вызовет столько внимания со [...]
Насчёт тэгов - поставил открывающий тэг php тут и комментарий обрезался дальше.. наверно его надо в html entity энкодить при показе, иначе он считается тэгом.. хотя я не эксперементировал.
Насчёт кэширования в принипе да, это надо делать отдельно, тем более если memcached есть и используется.
Про синтаксис это пожалуй самое главное. Я видел сайты написанные как сплошной php/html и даже с разделением логики на Controller-View (нечто типа theme в Joomla), впечатление было неприятное. Просто глаз не в состоянии быстро распознать хтмл тэги от пхп и приходится напрягаться просто что-бы понять где переменные а где оформление, я уж не говорю если замешаны вложенные if-else или циклы с объектами.
Smarty всё-таки ограничивает своим псевдо-языком возможности разработчика по использованию как сложных структур так и глобальных переменных. Всё что небыло передано напрямую через assign просто не существует. Эту чёткость потока данных я и имел ввиду под искушением использовать глобальные переменные.
Просто архитектура потока может быть древоподобной, либо как сеть, где всюду используется общие ресурсы - функции, переменные. И в последней архитектуре разбираться сложней новичку.
Артём Курапов,
Насчёт тэгов - поставил открывающий тэг php тут и комментарий обрезался дальше.. наверно его надо в html entity энкодить при показе, иначе он считается тэгом.. хотя я не эксперементировал.
Странно. Хотя я тоже не экспериментировал - нет времени ))) Попробуйте конструкцию <pre><code>…</code></pre>
На счет того, что глазу сложно привыкнуть к синтаксису - так это зависит от редактора и от привычки. Всему нужно учиться и к некоторому нужно привыкнуть (кто-то привык к Windows, кто-то к Linux, а кому и MacOS душу греет :) )
В общем, я пришел к выводу, что каждый выбирает то, что ему больше нравиться и подходит для данной ситуации.
Я для себя выбор сделал. Поделился этим с вами, но я не заставляю вас идти по моему пути. Я просто показал еще одну тропинку, не мною открытую, но я по ней иду. :)
Как я уже говорил, Smarty “рулит” для клиентских приложений с небольшой нагрузкой, когда идет разделение труда программист-верстальщик.
Но для приложений где важна скорость, ИМХО, Smarty неповоротливый монстр. Без которого с легкостью можно обойтись.
Я тут посмотрел пример в действии (нашел наконец время 4:16 утра :) ) и меня это натолкнуло на мысль:
такой подход дает большую гибкость при построенни разного рода “движков”.
Если система документирована и входные/выходные данные и их форматы описаны и определены, то проблем особо не должно возникнуть для верстальщика шаблона.
Ну, это да…
cyberfox, спасибо что нашел время, тем более такое оригинальное - 4 утра =)
А как ты смотрел его в действии? Применил в каком-то проекте?
Пока что нет, но возможно сайт Smolensk Linux User Group будет использовать эту фичу (но пока что он на Smarty).
Ближе к утру ознакомился с Zend Framework, наталкнуло на мысли, особенно когда нашел посто о сравнении производительности MCV фреймворков:
http://www.alrond.com/ru/2007/feb/04/dopolnenie-k-test-mvc-frameworks/
На какие мысли?
Ну, какие тут могут быть мысли? Питон с Django делает всё и вся с большим отрывом и при этом довольно-таки стройный и продуманый.
На php, к сожалению, чем стройней, тем медленней. Внутренности CodeIgniter - это просто жесть, но работает он очень даже быстро, что наводит на мысль, что так и задумано…
в функции _strip забыты обратные слеши у спецсипмолов
Ой, точно! И за столько комментов никто не заметил…
Они не забыты, это просто при вставке их WP порезал… Сейчас попробую поправить, хотя после такого количества пива не обещаю ))))
Sylvio, спасибо за внимательность! Поправил.
Браво!- За замечательную статью.
Спасибо. :))) Никак не ожидал столь высокой оценки ))
Да и такого количества комментариев не ожидал.
Главное - вовремя затеять спор ;)
Я ж нечаянно. =)))
Кстати на счет спора. Интересный спор получился на тему кэширования. Присоединяйтесь пожалуйста, а то нам вдвоем с vasa_c довольно сложно подытожить тему.
Мда, начал читать и было подумал что автору наконец пришла в голову очевидная мысль, но после фразы
“за 10 минут написал свой простенький шаблонизатор” я разочаровался…
php сам по себе шаблонизатор, не надо изобретать велосипедов
=) А я разве говорил другое???? Вы не так поняли мою фразу: “за 10 минут написал свой простенький шаблонизатор”
Эта статья, как раз и была написана в защиту того, что PHP сам по себе прекрасный шаблонизатор.
Почитайте статью еще раз, а так же обратите внимание на комментарии
В чём?
и что вы используете в качёстве View?
class VIEW_View :)
В каком смысле? Вы используете в проектах мой VIEW_View? Или что? :)
bananos@developer.co.ua, куда вы пропали? Я по прежнему жду вашего ответа, на вопросы Patrick‘а.
Я про то, что все нормальные самописные шаблонизаторы похожи на class VIEW_View. Мой правда уже оброс неслабо… Layout-ы, хэлперы и т.д. Но смысл тот же.
Не думаю, что bananos@developer.co.ua придумал что-то очень уж отличающееся.
Sam Хэлперы это из “другой” оперы…. Не думаю что лучшем решением будет напрямую включать их во View.
Почему же? Это довольно распросранённая и удобная практика. См. CakePHP, CodeIgniter.
[...] очень похож на ряд велосипедов включая мой: HSTamplate, Прощай Smarty или простой шаблонизатор, Шаблонизировать за 6 секунд (и 6 строк) [...]
Может, я чё не то делаю, но при запуске тестовой странички из твоих примеров меня сразу выкидывают с грязными ругательствами: 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 не правильная?
Stan
У тебя случаем не PHP4?
Да, он самый - 4.4.4 кажись. В помойку? На пятый пора переходить?
Пора. Четвёрка официально больше не поддерживается.
У моего хостера тоже 4.4.4, облом :) Ладно, поставил я себе php5, запускаю - оппа! Что-то не нравится ему в строке $view = new View(’/tpl/’); Говорит, что Fatal error: Class ‘View’ not found в этой строке. Может, опять что-то не хватает? :)
$view = new VIEW_View(’/tpl/’);
@Sam, большое спасибо за помощь! =)))
@Stan, будь чуть внимательнее, а если, что пиши поможем. =)
Не плохая сатья. Я в нете долго искал на подобие такой. Спасибо!!
Спасибо. Сразу после прочтения стал использовать вышеприведённый класс.
Но нашлось одно НО: информация внутри тэгов и выводится не так, как хотелось бы :(
Урс… Внутри тэгов: <pre> и <xmp>.
А как именно хочется и как выводится?
Никита, приведите пожалуйста пример кода, при помощи которого “не так выводится информация”
ОК. Например, код
array
(
[0] => ‘param’,
…
[n] => ‘param’
)
, удобный для просмотра массивов, после передачи через $view->display(’template’) становится таким:
Array
(
[0] => ‘param’,
…
[n] => ‘param’
)
, что не очень удобно для просмотра многомерных массивов.
Также через тоже удобно писать листинги кода и т.д. Но нужно иметь возможность сохранять предусмотренные отступы.
Блин!!!
В первом примере код такой:
Array(
[0] => ‘param’,
…
[n] => ‘param’
)
Неоднократно поднимал подобный вопрос.
Наиболее распространенный ответ: “а вот разница”.
php-теги обрезались
@vasa_c
И зачем смотреть на тех кто отвечает “а вот разница”.
По моему, они просто хотят похоливарить, и все )
Для вас есть разница писать:
{$title}
или
< ?php echo $title?>
?
З.Ы. Чтоб не резались php- и html-теги вставляйте их между тегами code
Первый вариант читабельней.
Так чуть читабельней:
Блин! Ненавижу этот WP :(
Что-то пост зарос камментами, видимо тема актуальная. Я после знакомства с CakePHP забыл что такое Smarty вообще.
@cyberfox
Конечно, актуальная. Люди наконец начали осознавать, что PHP сам по себе очень мощный шаблонизатор.
И лучше использовать машинные ресурсы на что-либо другое, нежели на перевод с одного псевдоязыка на PHP.
И давно ты работаешь на CakePHP? Уже есть готовые проекты?
Нет, не давно, но успехи небольшие есть. Я нахожусь в данный момент в стадии познания технологии и попутно пеку сайт linux user group со старого движка.
Мне кажется, что ели уж экономить ресурсы, то надо начинать с отказа от самого php. А раз уж использовать его, то потери на шаблонизатор уже можно не учитывать.
@Daev
Тоже вариант, но какой-то радикальный =)
В принципе, спор затянулся и спорить можно бесконечно, на некоторых проектах нативные шаблоны действительно дают выигрыш в производительности, на некоторых его не заметно.
Но, для себя я точно определил, что Сматри - это ненужный костыль, для PHP.
Сторонники Smarty, могут кидать в меня камни… а может кто-нить из них одумается… а может одумаюсь я =)))
Все может быть.
ping.
из дома ничего не доходит.
Меня забанили? )
vasa_c, конечно нет!
Я рад активным комментаторам
А будет ли прирост производительности если передавать не копии а линки на переменные?
Конечно это добавит ограничения, но хотелось бы знать реальные цифры, стоит или нет.
public function set($name, &$value)
{
$this->_var[$name] = &$value;
}
SergiusD, неа.
http://pyha.ru/forum/topic/259.msg3331#msg3331
Подскажите пожалуйста для чего нужна функция
private function _strip($data)
сначала думал что она убирает символы перевода строки и тп в шаблоне, то есть бесполезные с точки зрения html, но потом увидел что слеши экранированные. И зачем двойной пробел заменяеть на пустоту?
SergiusD
Вы все правильно думали
Она убирает символы перевода строки во всех системах (Win, *nix, Mac), плюс убирает двойной пробел и табуляцию, т.к. эти символы так же не существенны для браузера.
Если парой слов - то это функция вытягивает весь HTML-код в одну строку.
Гм… нехорошо. Тогда уж убирать их только между > и <
Кого их и почему?
Это я про _strip. Представь, что есть у нас тэг pre. Или же неразрывная строчка с 3-мя пробелами или ещё что…
@Sam
Хм…
Верно! Это я упустил - косяк )
Кстати, у меня были на счет этого проблемы с JS-вставками, некоторые переставали работать при вытягивании в строку.
Может подскажешь как сделать аналог блока {literal}…{/literal} в Smarty. Т.е. что б тег между определенными тегами не вытягивался в строку.
Я понимаю, что это делается через регулярки, но как это сделать максимально красиво? Вот в чем вопрос.
Максимально красиво с этим не заморачиваться!!!
@admin
Ну если уж убирать эти символы то в надо поправить в методе _strip 2 слэша на один слэш.. потому что она хочет менять сочетание символов \n а не сам перевод chr(10).
Если это сделано просто для экономии трафика то согласен с Andrey’ем что проще не мучаться, а использовать gzip-ование страниц перед отправкой
@all
Если честно, сам эту функцию использовал всего пару раз =), а потом отказался от нее за ненадобностью. По-моему, сейчас уже нет насущной проблемы по экономии трафика.
Если уж продолжить домогаться до мелочей, то заменять переносы строк на пустоту некорректно. Две строки слипнутся в одну.
Да, и вы забыли одиночный \r. И, кстати, тогда последовательности \r\n \n\r не нужно указывать.
И в str_replace вторым аргументом можно указать просто “”.
И кроме PRE и SCRIPT, еще есть TEXTAREA и много чего.
+ Все атрибуты тегов.
+ Шаблонизатор не должен сам делать предположений, что нужно в верстке, а что нет.
+ У меня из дома не пишется, что это может быть?
:)
@vasa_c
Согласен.
Тоже согласен, поэтому этим методом и не пользуюсь =)))
А дома, случаем не спутниковый интернет?
Нет. Обычный.
Причем если послать второй раз тоже сообщение пишет, что попытка дубля.
Я делал вот так:
$compressed = preg_replace("~>(\s+|\t+|\n+)<", $pagedata);@Sam
Ты кажется в функции preg_replace пропустил, один параметр.
А так идейка ничего, надо попробовать ))))
Вот рабочий вариант, который удовлетворит все описанные выше требования
$compressed = preg_replace("@>(\s+|\t+|\n+)< @", '>< ', $html)Это просто чуть исправленный пример Sam‘а.
:)
Проверял?
У меня, кстати, просто строчку покоцал этот WP :(
@Sam
Конечно, проверял. Даже в исходниках в своих заменил =)
Правда, я в исходниках добавил еще теги {literal}{/literal}
Между ними код вообще не обрабатывается. Это очень нужная вещь.
Мне пробел после < ужас как не нравится…
@Sam
Мне тоже, но сделать с этим ничего не смог, это происки WP.
Спасибо за статью. А то я уж было подумал, что мне одному казалось, что Smarty - очень утлая замена php
Постарался немного разобраться в данном вопросе.
http://pyha.ru/forum/topic/659.0
@AlexB,
правда у вас там получился не разбор вопроса, а реклама шаблонизатора Blitz, ну да ладно =).
А вообще, по прошествии некоторого времени я понял, что вопрос выбора шаблонизатора - это скорее вопрос религии )
Да нет, в общем, старался реально разобратся в вопросе и как-то упорядочить все.
Ну Blitz это да, пока ничего более удобного не попадалось. Но за рекламу мне не платили :) просто такие выводы у меня вышли.
Ну я ж не говорю, что реклама коммерческая )))
Мне тоже Blitz понравился, правда, я еще не представилось случаю испробовать его на реальном проекте.
[...] Прощай Smarty или простой шаблонизатор pdf [...]
У меня возник вопрос касающийся статьи.
Объясню на примере форума. Есть список тем, тоесть один ряд который приходиться инклудить например 30 раз. Это нормально?
И второй вопрос про фигурные скобки.
$loadedTpl = file_get_contents($this->_template);
foreach ($this->_var as $key => $val){
$loadedTpl = str_replace(”{”. $key .”}”, $val, $loadedTpl);
}
и соответственно
{title}
так плохо?
не судите строго, я начинающий :)
@Max
Я немножко вас не понял… что значит инклудить 30 раз? Покажите пример кода.
А вообще итерации (повторения в теле цикла) это нормально.
Если проект не критичен к нагрузке, то нормально. Хотя, если нет критичности по скорости выполнения, то лучше использовать Smarty. В других, же случаях я предпочитаю использовать “нативные” (php) шаблоны. Либо же шаблонизатор WACT, но php-шаблоны, ИМХО, легче.
Есть повторяющийся html код, как например пост на форуме. Постов нужно вставить 30 штук, каждый раз подставляя переменные с другими значениями, т.е. нужен цикл, который, исходя из вашей статьи буедт 30 раз инклудить оидн и тот же файл. Вот тут и возникает вопрос про нагрузку.
Объясните пожалуйста из-за чего именно критичность. Из-за file_get_contents или str_replace. Т.к. в повторяющихся кусках кода file_get_contents() ипользуется только оидн раз, а далее идет только замена.
Я так понимаю с иклудом быстрее? Спасибо.
@Max
Делайте просто include, и все будет хорошо.
Если проект небольшой (до 50 000 - 100 000 хитов), то ни в чем. А так str_replace не самая быстрая функция, хотя опять же это сказывается на больших объемах данных и при большом количестве итераций. Т.е. если шаблон у вас огромный и число итераций измеряется тысячами.
Вы пишете:
>чтобы шаблонизатор потом постоянно перегонял эти
>шаблоны в PHP-код (куча никому не нужной работы!!!)
Smarty компилирует шаблон в php файл ОДИН раз, потом дергает этот php файл. Кроме того у него есть кеширование, которое если правильно организовать, дает очень неплохие результаты.
Кто то не доганяет для чего нужен шаблонизатор.
Чтобы пользователи которые имеют право на запись в шаблоны не имели доступа к php. (темы для блогов например) …
Лично я не навижу PHP перемешанный с HTML и независимо он того кто верстает страницы, дизайнер или программист, котлеты должны бить отдельно а мухи отдельно.
Сила смарти в том что он популярней всех остальных шаблонизаторов, и становится стандартом. Самая главная проблема всех PHP-шников и самый большой недостаток PHP, в том что нет четкой структуры как в яве.
Мне попадаются всякие сайты на доработку и иногда диву даешся какой может быть ламерский код, некоторые начинающие программисты умудряются почесать левой пяткой правое ухо. Реальный пример когда 1500 строчек дикого php кода, которого не в состоянии нормальный человек вникнуть вообще, первращается в 15 строчек и небольшой шаблончик. И самое плохое что большенство так и программирует изобретая велосипед, и тратя недели на то что можно сделать за час, а все потому что нет стандартов.
Так что Ларин =) учите мат.часть
Да а эту статью я лучше бы удалил =)
dLex, смешно!!!!!
Roman, ну покажите мне шаблон на Java, точней на JSP.
@dLex
Вы мне предлогаете учить мат. часть???
=) =) =) =) =) =) =) =) =)
Что смешного ? =)
не довать доступ к php
А статью удалил бы потому что класс написаный вами не возможно назвать шаблонизатором.
1 Я хочу сначала подгрузить шаблон №1 и выполнить парсер , но отдовать нечего пользователю не буду, потом шаблон №2 и №3
и только потом если все хорошо отдать пользователю =) html
2 ob_start(); ob_get_clean(); - у меня меня просто нет слов
3 $_SERVER['DOCUMENT_ROOT'] - отлично будет работать на IIS =)
ну как с твоим классом 1 вариант вкатит ?
Короче узай include($tmpl) =)
Короче это даже не велосипед =) тут колесо причем которое нельзя установить на велосипед =)
Так что Smarty учись настраивать и не грузить все его 300 кб =) и править
xml xslt - вот в чем сила брат
dLex
А что не так с ob_start(); ob_get_clean();?
Выскажусь по теме:
Раньше использовал Smarty, но как перешел на cakePHP
необходимость в нем отпала, как и в QuickForm.
Всегда считал, что PHP сам по себе шаблонизатор.
Всем доброго здравия.
В данный момент работаю программистом и верстальщиком, был во фрилансе почти 2 года…
Скажу лишь одну фразу. Smarty - остается Smarty, PHP - остается PHP…
Два колеса не могут крутиться в разных направлениях. Золотая середина появиться лишь тогда когда верстальщик будет знать и Smarty и PHP в равной степени, чтобы разбираться в коде. Ему еще нужно будет думать об кроссбраузерности и многих других вещах, нежели вести споры о “моде”.
____Из личного опыта_____
Всем спасибо. Ах. да. Пост…-Смарти - в топку. Все гениальное просто (Include).
Без нормального кеша твой шаблонизатор для смарти не конкурент.
@NETMAN
Читай статьи дальше, там еще 2 статьи о кеше )))
последние несколько месяцев стал выносить всю логику из Smarty в php код, быстродействие немного увеличилось. В итоге шаблон содержит только циклы и выводы переменных. Отсюда вывод - для таких целей ну никак не требуется дополнительныё 150кб класс.
Кто видел в каком виде компилируются шаблоны Smarty? Этож полный ахтунг.
Кстати кеширование Smarty не всегда даёт прирост производительности, иногда наоборот замедление.
Циклы одно из узких мест в PHP, поэтому не рекомендую одни и те же данные гонять в разных циклах. Достаточно в одном цикле обработать их и тут же проверстать в блок шаблона.
Smarty придуман, скорее, для сервисов, в качестве доступа аккаунтов к о*уенным серверным возможностям, чего и требуют аккаунты, но доступ, разумеется, в ограничительных рамках. И как иначе, ты, это сделаешь? Не давать же кому-угодно ковыряться в php-кодах всего сайта?
полная херня написана
Это ж надо было такой бред сморозить…
Здравствуйте… по моему шаблонизатор совсем не очень…
1) обязательно нужна функция fetch - ибо толку от шаблонизатора такого ?
2) зачем нужен шаблонизатор без кэширования ? можно просто инклудить шаблон, или ты это сделал чтобы переменные не смешивались ?
3) если программист не пишет в шаблоне $this - это большой плюс, а не лень! this вообще нет смысла писать так как ты используешь в шаблоне локальные переменные функции или класа + глобальные переменные, но я их не использую обычно…
@Djinn
Привет!
1) Функция fetch появилась на следующий день после написания статьи (добавлять было лень)). Я думаю, ее не сложно выделить из метода display, и чуток дописать )
2) Для удобства и структуризации )
3) В принципе, с этим согласен.
Вообще же в свете последнего перехода на Джанго… данный шаблонизатор просто позор на мои седины ) Хотя для того времени было нормально, главное он выполнял все поставленные перед ним задачи (правда, в несколько изменном виде)
Наткнулся на эту статью… Проблема по поводу шаблонизаторов появилась в начале 07 года. И только вот сейчас я встретил статью, в которой вполне ясно описано.
Какого вы мнения о FastTemplate ? Модная вещь была когда-то.
Почему Django а не RoR ?
Сколько вам лет, гражданин программист,
и почему предложенный вами шаблонизатор (я б его пользовал только для “2) Для удобства и структуризации )”) спустя два года вы назвали позором.
Хочу его пользовать, так что интересно, что может быть в нём плохого.
Вы пока подумайте, а я скопирую его себе ))
@Petr
Модная, но не более. По мне Smarty намного лучше ) Но это конечно, субъективно.
Красота и гибкость языка Python меня покорили ) Так же понравилась сама идеология Django.
Об этом лучше умолчать ))))
Я постоянно учусь новому, развиваюсь и по новому смотрю на уже привычные вещи. И мой код, написанный, скажем 5 лет назад, иногда вызывает у меня улыбку, а иногда и ужас =)
Это скорее не шаблонизатор, а некий класс-хранилище )
Да и после Django не могу смотреть на шаблонизаторы без поддержки наследования шаблонов )
самое смешное, что это тоже смое, что и
)) ибо \s = [:space:]+\r+\n
Я не обломался, все посты прочитал. Вы далеко не уходите от темы. О какой экономии Вы говорите, что значит в два три раза … что это, на 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.
ой … забыл не маловажное! И даже очень важное! Это 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 :)
По поводу оптимизации всегда будет много споров, использование кэширование(разного типа) и акселераторов. Очень много зависит как и от организации самой системы(программы) так и от сервера, и так же имеет фактор такой, как написание самого кода!
и или огого сколько
вот даже в такой сказалось ситуации можно выиграть огого сколько
Привет, Мик!
С момента написания статьи прошло более 2-х лет, и по прошествии этого времени я уже могу сказать - данный шаблонизатор не удобен ))) По правде говоря он вообще шаблонизатором не является, это просто класс-контейнер с данными и методами для работы с этими данными.
Но! На тот момент на одном из проектов данный подход действительно давал выигрыш и по времени, и по памяти.
Проект не использовал ни ZF, ни других сторонних FW. FW был свой, с минимумом слоев абстракции, максимально рассчитанный на быструю работу.
Но сейчас условия изменились и иногда бывает проще поставить еще один сервер, но работать с удобным шаблонизатором.
Опять же, все зависит от задачи!
Ой пардон! дату поста не усмотрел) Конечно же, задачи и ставят определённые рамки в использование того или иного подхода(с тем же шаблонизатором). Просто если встречаются какие то недостатки или чего то не хватает, я думаю не трудно дополнить или изменить. В особенности со Smarty, у меня написаны множество модификаторов и функций, которые приводят выходящие данные к приятному виду. И с каждым проектом эти модификаторы постоянно пополняются. Просто объектно-ориентировочный подход уже даёт снижение производительности, но это снижение не ни что, по сравнению с тем, какие преимущества выходят при использование этого подхода. Smarty по моему мнению оптимальный вариант из ряда шаблонизаторов, который можно легко расширять под свои нужды(задачи) без особых проблем.
Хотелось бы чтобы те, кто не прочитал все комменты :) к посту, не сделали вывод, что Smarty это плохое решение. И не сказать что тут дело вкуса, скорее дело в правильной и обоснованной оценки при выборе того или иного решения.
Спасибо за пост Larin! Приятно было почитать всю эту дискуссию, хоть и времени ушло многовато :)
MikJager, пожалуйста!
Приятно, то мои посты приносят людям хоть какую-то пользу )
Нормальный ман взял бы и написал….
а то ищете как поднять производительность….
какая нахрен производительность если всё методом тыка проверяется….
Мегадискуссия :)
В проектах, где к коду шаблонов должны иметь доступ “верстальщики” использование шаблонов считаю более-менее оправданным..
В основном же склоняюсь к php-”шаблонам” + при необходимости - кэшированию (естественно, разумному).
PS. спасибо автору за статью, всем комментаторам - за активное обсуждение :) Хотя, позиция некоторых мне мягко говоря не близка…