Чем это улучше обвертки+фабрики?
для использования обвертки+фабрики для шаблонизатора недостаточно, по этому необходим еще один логический уровень - формирование данных.
Пусть необходимо вывести таблицу, мы имеем
PHP:
$t = MyTemplate::GetInstance();
$t->GetInstanceTmpl->GetInstance('smarty', $settings);
$t->Assign( 'tmp', $arrOfvar );
echo $t->Fetch( 'test.tpl' );
// code 2
$t->GetInstanceTmpl->GetInstance('xslt', $settings);
$t->Assign( 'tmp', $xmlOfvar );
echo $t->Fetch( 'test.xsl' );
Для первого случая мы в переменной $arrOfvar формируем двухмерный массив,
во втором примере мы в переменной $xmlOfvar формируем XML
если использовать третий вид шаблонизатора, то придется формировать еще какой-то иной вид данных.
По этому нужен некий промежуточный вид представления данных и некий класс-контрейнер, который бы его приведил к соответствующему виду для шаблонизатора.
что-то типа
Код:
$t->GetInstanceTmpl->GetInstance('smarty', $settings, new ArrayCollector ($inputData));
$t->GetInstanceTmpl->GetInstance('xslt', $settings, new XMLCollector ($inputData));
вопрос, что делать с Методом $t->Assign( );
Это я к тому, что может появиться куча дополнительных производных классов
ArrayCollector ($inputData)
ArrayVlibCollector ($inputData)
ArrayWactCollector ($inputData)
которые приводят данные в соответствии с интерфейсами, с учетом ньюансов каждого шаблонизатора.
есть еще куча всяких ньюансов в разных шаблонизаторах, как подшаблоны, инклуды, пути, контексты, плагины, функции обратного вызова, идентификаторы кеширования и т.д. ...
на все замучаешься писать обертки
Про это и говорил Фaнат, когда имел ввиду, что если начнешь писать что-то уневерсальное, то кол-во ньюансов кода превысит реализацию самого ядра.
Вопрос - нужно-ли это?