Незнаю. У меня шаблонизатор на базе которого писался этот (80% кода осталось без изменений) был написан в 2003-м, и ни одного бага не было (этапы отладки при изменении API я не считаю - баги это то что попало в релиз). Так что как в том анекдоте - "Вас что не учили мыть руки после туалета? Нет нас учили не писать на руки".
Конечно ошибки есть у всех, и наверняка во всем движке частью которого является этот шаблонизатор будут баги. Куда ж без них то
Я к тому, что если проект не слишком сложный то "фиксятся баги" никак не может быть его достоинством - это все равно что сказать "его преимущество в том что он работает"
Раз уж "фиксятся баги" попало в достоинства то это говорит как раз о том что он СЛИШКОМ сложный... неоправданно сложный.
Огромный возможности, легко расширяется
90% из которых нафиг никому не нужны и используются единицами.
Это тоже идет в минус Смарти.
Главное в шаблонизаторе - возможность его расширения.
Главное в шаблонизаторе - простота. Вторым идет функциональность. Расширяемость это минус.
К примеру, поддержка виджетов, поддержка мультиязычности (вставка фраз на разных языках).
Виджеты это у нас кто? Если я правильно вас понял то для этого есть хуки. Все остальное от лукавого.
Мультиязычность - во вьюве (класс наследующий шаблонизатору) у меня есть метод "ланг" который читает файл со строковыми переменными (в основном для языковых файлов, отсюда и название) и добавляет их в массив переменых. Дальше они используются как обычные переменные в шаблоне.
Использование "бакса" {$var} в переменных визуально отделяет их от тегов. К примеру, можно объявить переменную {$doit} а можно объявить вызов ф-ции {doit} или {doit}xxx{/doit}. Доллар решает эту проблему.
Раньше я использовал более простой шаблонизатор и каждый раз в контроллерах приходилось делать кучу assign'ов, + надо было заботиться об экранировании переменных.
Часто в шаблонах менялась логика и в 90% случаях можно было обойтись правкой шаблона, но приходилось дополнительно делать изменение и в контроллере. Smarty решил эти проблемы, теперь в контроллер залезаю намного реже. Приведу даже пример:
PHP:
$user = new User();
$view->assign( 'user', $user );
шаблон
Код:
Привет, {$user->getName()|escape}
так бы пришлось передать юзернейм отдельно и заэкранировать его.
Это не есть задача верстальщика парится о ваших экранированиях. Программисту вообще нечего делать в шаблоне. В принципе нечего.
Я даже метод сейчас думаю написать автоматической генерации шаблонов при их отсутствии... чтобы уже верстальщик парился с их оформлением а для примера и автогенериного сойдет. Но пока руки не доходят, хоть и ничего сложного.
Или в интернет-магазине передаётся объект продукта и в шаблоне иногда нужно использовать цену в raw формате 1500.10 (для подстановки в javascript), а в остальных случаях в отформатированом виде: 1 500 руб. 10 коп.
незнаю. Помоему не так сложно передать рубли отдельно а копейки отдельно и выводить их или {rub} рублей {kop} копеек
или {rub}.{kop}
немного сложнее но зато не надо задумываться о синтаксисе...
(даже задумываться не буду как это усложнить.. в смысле упростить... все равно усложню)
Ещё пример: поддержка форм в шаблонах что-то вроде
Код:
{form name="myform"}
{input name="x"}
{select name="y"}
{/form}
Сами формы создаются в контроллере и при ошибках валидации подсвечиваются, автозаполняются и т.п.
Если при каждом нестандартном случае Вам придётся править код шаблонизатора - это неправильно.
Перемудрено. Создал себе форму ручками и не морочишь себе голову.
Я дико извиняюсь, но не мог бы ли ты дать ссылочку на ветку на серче, где рассказывают как избавиться от шаблонизатора.
Да нет там ничего разумного. Но все равно
Для просмотра ссылки Войди или Зарегистрируйся.
ТС просил привести примеры.
Многомерный массив.
Допустим если некий массив
Код:
array('vasa','street','country','state','actions'=>'delete','edit','block','unblock')
Дальше там другие васи,пети,вани и тп.
Задача - показать список и вывести список доступных действий,учитывая что действия могут быть разные и список их создается еще до передачи парсеру.
В вашей системе это нереализуемо ?!
Спасибо за пример.
Не совсем понял ваш синтаксис. Но думаю вы имели ввиду чтото вроде:
PHP:
$people=arrray();
$people[]=array('name'=>'Вася','age'=>29,'actions'=>array(
'delete','edit','block','unblock','view'
),'comment'=>'Свой клиент');
$people[]=array('name'=>'Петя','age'=>29,'actions'=>array(
'view'
),'comment'=>'Чужой клиент');
Действительно такой синтаксис удобнее чем if-ами делать для каждого потенциального поля.
И тут еще вопрос переменных массива без индексов, т.е. когда в массиве только одна переменная можно синтаксис упростить. Подумаю над этим, это думаю реализую спасибо.
Что касается обьектов, это можно заменить системой плагинов,но у вас плагинов нету,как я понял? А разрабатывать шаблон в таких "зажатых" условиях даже врагу не пожелаешь.
Есть хуки, что вам еще надобно?
Ну а в ядре система плагинов да, предусмотрена...
хуки в шаблонизаторе сделаны именно для плагинов
тестировать скрипт на предмет скорости- если не будет хотя бы середнячком, то опустят сразу.
Таки выделил полчаса на тесты.
Технология теста:
Код:
грузим модуль
забиваем данные в модуль
засекаем время
в цикле тысячу раз выполняем шаблон
выводим время деленное на тысячу
такой подход показывает только время парсинга и не учитывает время подключения файла шаблонизатора (один файл), время выполнения методов передачи данных в шаблон, не учитывает время на собственно вывод данных в браузер и т.п.
Считаю что методы вида:
PHP:
public function set($name,$data)
{
// Если имя переменной не body то добавим ее в массив
if($name<>'body') $this->var_array[$name]=$data;
}
не стоят оптимизации и оценки скорости их выполнения.
Результаты теста:
Шаблон "сферический конь в вакууме" из двух файлов общим размером в 380 байт с одним массивом внутри, парочкой if и переменных выполнялся
0,001сек
Реальный шаблон, довольно кривой (верстка таблицами, куча мусора) количество файлов - 9 шт (инклюды, вложенные инклюды, хуки и тп) - все выводятся на странице. общий размер файлов 10кб. два хука, два массива, несколько if пару переменных. Не самый сложный шаблон, но и не самый простой. В общем "типичный" так сказать.
Результат -
0.0043сек
Смотрел я в код - там куча мест для оптимизации - уверен что можно раза в два скорость поднять
свободно, но я не буду этого делать в ближайшем времени. Глупо заниматься нанооптимизацией - сильно нагруженный шаблон явно будет парсится быстрее чем у большинства пользователей будет до него пинг
Про синтаксис вы не здесь спрашиваете. Для кого вы делаете шаблонизатор? Для прогеров или сеошникв? Нужно спрашивать более-менее профессиональных верстальщико, которые знают что хотят. И заставить их написать сочинение на тему "Каким я вижу идеальный шаблонизатор". И от этого отталкиваться.
Где живут идеальные верстальщики?
в разделе Дизайнеризма?
Ибо моё мнение, писать свой шаблонизатор- можно только под конкретные нужды (напр. оптимизированная под конкретный тип сайта или дизайнерской студии). Могу назвать Массу причин, хотя думаю, вы здесь не за этим. 
