Templus vs HTML_Template_Sigma

Varcom

Новичок
Templus vs HTML_Template_Sigma

Специально для voituk
Делаем вывод - Templus в данном случае удобнее FastTempate отсутсвием необхоимости определять блоки.
Но ведь на FastTemplate свет клином не сошелся - есть например HTML_Template_Sigma , разработанный Sad Spirit.
Опять же делаем вывод, что ничего нового, кроме альтернативного синтаксиса и непонятных констант Templus не демострирует.
Я начал изучать HTML_Template_Sigma. Честно говоря, знакомство с этим средством не очень впечатлило. Есть немного от моей идеологии - все шаблоны и подшаблоны собраны в одну страничку, в том виде в каком они будут отображаться. Только вот, реализована эта идеология слегка криво.
Приведу некоторые аргументы после первого знакомства.

1. Шаблонизатор Sigma не делает синтаксической проверки корректности шаблона.
Открывающий маркер блока без закрывающего будет воспринят как простой текст.
<!-- BEGIN test -->

Шаблонизатор Templus отругается, что в шаблоне имеется ошибка, нет закрывающего маркера.
<!--{test{-->

2. В шаблонизаторе Templus используется объектная модель организации данных. Это значит, каждый шаблон, каждый вложенный блок, каждая переменная - это отдельный объект. Вы можете получить указатель на любой объект в шаблоне и управлять его свойствами. Обращение к вложенным объектам происходит, через родительские объекты. Причем сам корневой шаблон, является таким же объектом, как вложенные в него подшаблоны (блоки), имеет те же самые методы и свойства. Поэтому управление корневым шаблоном и всеми вложенными в него подшаблонами производится идентично.
В шаблонизаторе Sigma, сам корневой шаблон и вложенные в него блоки являются разными сущностями. Т.е. доступ к тем и другим осуществляется по разным правилам. После загрузки шаблона, все блоки и все переменные хранятся в плоском виде - в виде массива блоков и массива переменных. Отсюда начинаются проблемы:
а) в коде программы эти блоки логически никак не связаны. Это значит, программисту, просматривающему программу после нескольких месяцев от предыдущей правки, тяжелее будет разобраться в логике.
Сравните код:
PHP:
// Sigma
  $tpl->setCurrentBlock('template2');
  $tpl->parseCurrentBlock();
  $tpl->setCurrentBlock('template1');
  $tpl->parseCurrentBlock();
и
PHP:
// Templus
  $tplTemplate1 = $Template->Child('Template1');
  $tplTemplate2 = $tplTemplate1->Child('Template2');
  $tplTemplate2->Evaluate();
  $tplTemplate1->Evaluate();
или тоже самое в сокращенном виде:
PHP:
  $Template->Child('Template1')->Child('Template2')->Evaluate();
  $Template->Child('Template1')->Evaluate();
Какой вариант говорит о логическом расположении блоков, их вложенности?

Справедливости ради надо сказать, что в Sigma есть процедура получения списка вложенных блоков. Но от этого слаще не становится. Выборка вложенного блока по имени превращается в геморрой.

б) В Sigma нельзя назвать два шаблона и две переменные одним именем, даже если они имеют разные уровни вложенности.
В Sigma нельзя написать нечто вроде:
PHP:
<!--{Table111{-->
<table>
    <!--{Row{-->
    <tr>
        <!--{Col{--><td> {$Value} </td><!--}Col}-->
    </tr>
    <!--}Row}-->
</table>
<!--{Table111{-->

<!--{Table222{-->
<table>
    <!--{Row{-->
    <tr>
        <!--{Col{--><td> {$Value} </td><!--}Col}-->
    </tr>
    <!--}Row}-->
</table>
<!--{Table222{-->
Программисту, работающем с Sigma придется каждый раз придумывать уникальное имя блока и переменной.

в) из б) следует, что нельзя написать процедуру обрабатывающую сущности с одинаковой структурой, вроде:
PHP:
function ProcTable($Table){
  $Table->Child('Row')->Child('Col')->Evaluate(array('Value'=>'1'));
  $Table->Child('Row')->Evaluate();
}
ProcTable($Table1);
ProcTable($Table2); // структуру таблиц смотри выше.
Остальные мысли приведу позже, в случае заинтерсованности.
 

Vladson

Сильнобухер
Re: Templus vs HTML_Template_Sigma

Автор оригинала: Varcom
Программисту, работающем с Sigma придется каждый раз придумывать уникальное имя блока и переменной.
О да, это самое сложное с чем ему придётся столкнуться на протяжении всего проекта :)
 

SmokyPython

Новичок
Varcom
Поюзал твой класс, довольно таки не плохо, но смущают несколько моментов

1.
$Table->Child('Row')->Child('Col')->Evaluate();
чем не угодило $Table->Row->Col? а метод Childs использовать как $Table->Childs(i)

2. Не рекурсивное Evaluate. Мне бы было бы комфортнее прописать необходимые свойства, а затем единственное $Template->Evaluate();

3. Твой первый же пример генерирует несколько notice'в

вобщето есть и в четвертых связанное с наследованием, но тут надо серьезнее посмотреть

а в целом идеология мне понравилась
 

Varcom

Новичок
Автор оригинала: SmokyPython
Varcom
Поюзал твой класс, довольно таки не плохо, но смущают несколько моментов

1. чем не угодило $Table->Row->Col? а метод Childs использовать как $Table->Childs(i)
а) $Table->Row->Col выгдядит лаконично, но с первого взгяда не понятно. Row и Col - это вложенные блоки, а создается ощущение, что это свойства или методы родительского объекта.
б) имя вложенного блока в шаблоне может совпасть с названием одного из стандартных свойств или методов объекта, произойдет коллизия.

2. Не рекурсивное Evaluate. Мне бы было бы комфортнее прописать необходимые свойства, а затем единственное $Template->Evaluate();
Не совсем представляю о чем ты. Приведи пример.
Вообще, вложенные блоки отображаются либо в цикле, либо в результате выполнения какого-то условия. Один общий Evaluate() в данном случае не поможет.
3. Твой первый же пример генерирует несколько notice'в
Процитируй. У меня не возникает.
 

Sad Spirit

мизантроп (Старожил PHPClub)
Команда форума
Жызнь прекрасна и удивительна.

Человечество напряглось, издало неприличный звук и на вопрос "что лучше --- Templus или Sigma?" дало однозначный ответ --- XSLT.

Сказки про разделение кода и представления --- таки да, сказки. На самом деле имеет смысл разделять бизнес-логику и логику представления, а для логики представления всё равно придётся напрячься и написать какие-то умные слова в шаблоне. В каком виде они будут --- вопрос десятый.

Во-о-о-от. Всем спокойной ночи, желаю помедитировать над сказанным.
 

SmokyPython

Новичок
Varcom
что это свойства или методы родительского объекта.
а это не так? Я имел ввиду что это общепринятая тенденция, что в Delphi/C пишется: Panel1.Button1, что в simplexml: mainbloc->childbloc, никаких child, все вложенные объекты это свойства данного объекта

имя вложенного блока в шаблоне может совпасть с названием одного из стандартных свойств или методов объекта, произойдет коллизия.
Какое огорчение, что же делать?

Не совсем представляю о чем ты
Ну да я чего то это не совсем учел, но я имел ввиду типа такого:
foreach($PersonalList as $Index => $Person){
$Template->PersonRow->SetParam(array(
'Id' => $Index+1,
'FIO' => $Person
));
}
$Template->Evaluate();

Процитируй. У меня не возникает.
Notice: Undefined property: Templus::$RootTemplate in C:\Inetpub\test\Templus\templus.php on line 371
Notice: Uninitialized string offset: 0 in C:\Inetpub\test\Templus\templus.php on line 225
 

Sad Spirit

мизантроп (Старожил PHPClub)
Команда форума
Автор оригинала: Varcom
Я начал изучать HTML_Template_Sigma. Честно говоря, знакомство с этим средством не очень впечатлило. Есть немного от моей идеологии - все шаблоны и подшаблоны собраны в одну страничку, в том виде в каком они будут отображаться. Только вот, реализована эта идеология слегка криво.
Приятно видеть человека, коему не грозит смерть от скромности. Вообще-то Sigma --- клон HTML_Template_IT, а этот движок даже в PEAR попал уже больше 5 лет как, до того развивался где-то ещё.

Кстати это можно считать и ответом на вопрос об API: в PHP4 несвежей версии писать
PHP:
$Template->Child('Template1')->Child('Template2')->Evaluate();
было несколько проблематично.

Если абстрагироваться от синтаксиса и API, то у Sigma есть два преимущества
1) Кэширование шаблонов. Оно там появилось не "чтобы было", кстати, а после выяснения того факта, что разбор шаблонов на каждой загрузке страницы не способствует быстродействию сайта.
2) Возможность задавать в шаблоне callback'и. Именно поэтому, например, отдельная сущность "разделитель" особо не нужна, её функциональность тривиально реализуется.

Хотелось бы, кстати, задать автору каверзный вопрос: есть такая стандартная фишка "полосатая таблица" (то бишь меняющийся цвет фона ячеек), как в этом форуме например. Как оно реализуется в Templus'е?


P.S. Но на самом деле все эти шаблонизаторы --- отстой, всё равно в шаблоне придётся использовать полноценный язык программирования. Фанат вот рекомендует PHP, я думаю что XSLT всё же более к месту...
 

Varcom

Новичок
Автор оригинала: Sad Spirit
Кстати это можно считать и ответом на вопрос об API: в PHP4 несвежей версии писать
PHP:
$Template->Child('Template1')->Child('Template2')->Evaluate();
было несколько проблематично.
Если какой-то используемый в движке синтаксис невозможно использовать в ранних версиях Php, это не значит, что движок плохо написан. Это значит, что ранние версии Php были не доработанные. И разработчики Php исправили эти недоработки в последующих версиях.
Тем более, что такой синтаксис обращения к объектам используется во всех объектно-ориентированных языках программирования. А еще, если помнишь, в четвертой версии Php присвоение объектов производилось по значению, а в пятой версии уже по ссылке, что, с точки зрения ООП более правильно.
Если абстрагироваться от синтаксиса и API, то у Sigma есть два преимущества
1) Кэширование шаблонов. Оно там появилось не "чтобы было", кстати, а после выяснения того факта, что разбор шаблонов на каждой загрузке страницы не способствует быстродействию сайта.
А кто сказал, что в Templus нет кэширования? Если скачать последний вариант шаблонизатора, то можно увидеть, что у объекта-шаблона есть функция MakeCache(), которая формирует содержимое кэш-файла. Причем в кэше хранится не какое-то "internal representation" содержимого шаблона, как в Sigma, а полноценный Php-код. Правда сами механизмы сохранения-восстановления кэша еще не готовы :) Но это дело времени. Главное, что кэш уже формируется.
2) Возможность задавать в шаблоне callback'и. Именно поэтому, например, отдельная сущность "разделитель" особо не нужна, её функциональность тривиально реализуется.
Этого в Templus не будет никогда. Sigma вообще характерен тем, что в шаблон переносится много программной логики. Это и callback'и, и блоки шаблона, которые сами решают, надо им отображаться или нет, в зависимости, присвоено ли значение переменной, и непонятные функции, типа blockExists() и т.д. Все это зло. Шаблон не должен содержать какой-либо программной логики, влияющей на формирование конечной страницы. Шаблон - это логическое представление концептуальной модели, и ничего более. Не должен дизайнер разрабатывать алгоритмы поведения шаблонов. А callback'и - это вообще полный атас. В Html-файле будет натыкана куча неизвестных функций, смысл которых будет понятен только тому дизайнеру, который их создавал, и абсолютно непонятен сторонним дизайнерам. И код обработки будет запружен кучей функций, назначение которых программист и не знает. Т.е. чтобы разобраться в назначении функции, дизайнер должен лезть в программный код, а программист - в Html-файл.
Хотелось бы, кстати, задать автору каверзный вопрос: есть такая стандартная фишка "полосатая таблица" (то бишь меняющийся цвет фона ячеек), как в этом форуме например. Как оно реализуется в Templus'е?
Так же как и должно реализоваться в шаблонах:

1. С помощью переменных
PHP:
  <td bgcolor={$Color}>{$Value}</td>
Значение переменной задается в программе.

2. С помощью стилей
PHP:
  <td 
    <!--{style1{-->bgcolor=$FFFFFF<!--}style1}--> 
    <!--{style2{-->bgcolor=$E0E0E0<!--}style2}-->
  >{$Value}</td>
3. С помощью подшаблонов
PHP:
<!--{WhiteRow{-->
<tr>
    <td bgcolor=$FFFFFF>{$Value}</td>
</tr>
<!--}WhiteRow}-->
<!--{GrayRow{-->
<tr>
    <td bgcolor=$E0E0E0>{$Value}</td>
</tr>
<!--}GrayRow}-->
Сначала выводитя первый подшаблон, потом второй, потом опять первый и т.д.

Первый вариант самый лаконичный, второй самый корректный.

P.S. Но на самом деле все эти шаблонизаторы --- отстой, всё равно в шаблоне придётся использовать полноценный язык программирования.
Совсем не обязательно. Мой шаблонизатор это демонстрирует.

-~{}~ 11.09.06 20:13:

Автор оригинала: Vladson
О да, это самое сложное с чем ему придётся столкнуться на протяжении всего проекта :)
А почему программист должен компенсировать недостатки шаблонизатора? Не лучше ли взять другой шаблонизатор, где нет этих недостатков?
 

voituk

прозревший
Varcom
Поздравляю - ты разработал идеальный шаблонизатор.
На этом предлагаю эту малоинформативную дискуссию завершить.
 

Sad Spirit

мизантроп (Старожил PHPClub)
Команда форума
Автор оригинала: Varcom
Если какой-то используемый в движке синтаксис невозможно использовать в ранних версиях Php, это не значит, что движок плохо написан. Это значит, что ранние версии Php были не доработанные. И разработчики Php исправили эти недоработки в последующих версиях.
Тем более, что такой синтаксис обращения к объектам используется во всех объектно-ориентированных языках программирования. А еще, если помнишь, в четвертой версии Php присвоение объектов производилось по значению, а в пятой версии уже по ссылке, что, с точки зрения ООП более правильно.
Правильно. И поэтому тыкать "более правильным" API Templus'а, каковой API просто невозможно было реализовать в той версии PHP, под которую писался H_T_Sigma достаточно глупо, ага? ;)

Этого в Templus не будет никогда. Sigma вообще характерен тем, что в шаблон переносится много программной логики. Это и callback'и, и блоки шаблона, которые сами решают, надо им отображаться или нет, в зависимости, присвоено ли значение переменной, и непонятные функции, типа blockExists() и т.д. Все это зло. Шаблон не должен содержать какой-либо программной логики, влияющей на формирование конечной страницы. Шаблон - это логическое представление концептуальной модели, и ничего более. Не должен дизайнер разрабатывать алгоритмы поведения шаблонов. А callback'и - это вообще полный атас. В Html-файле будет натыкана куча неизвестных функций, смысл которых будет понятен только тому дизайнеру, который их создавал, и абсолютно непонятен сторонним дизайнерам. И код обработки будет запружен кучей функций, назначение которых программист и не знает. Т.е. чтобы разобраться в назначении функции, дизайнер должен лезть в программный код, а программист - в Html-файл.
Про callback'и --- абсолютно пальцем в ж..у. Дизайнер, очевидно, не создаёт callback'и. Их пишет программист и говорит дизайнеру: ежели ты хочешь, чтобы у тебя менялись цвета ячеек таблицы, то пишешь вот такое заклинание, а если хочешь, чтобы у тебя разделитель выводился --- вот такое. А меня, скотина такая, не трогай по мелочам, я занят глобальными проблемами.

Так же как и должно реализоваться в шаблонах:

1. С помощью переменных
PHP:
  <td bgcolor={$Color}>{$Value}</td>
Значение переменной задается в программе.

2. С помощью стилей
PHP:
  <td 
    <!--{style1{-->bgcolor=$FFFFFF<!--}style1}--> 
    <!--{style2{-->bgcolor=$E0E0E0<!--}style2}-->
  >{$Value}</td>
3. С помощью подшаблонов
PHP:
<!--{WhiteRow{-->
<tr>
    <td bgcolor=$FFFFFF>{$Value}</td>
</tr>
<!--}WhiteRow}-->
<!--{GrayRow{-->
<tr>
    <td bgcolor=$E0E0E0>{$Value}</td>
</tr>
<!--}GrayRow}-->
Сначала выводитя первый подшаблон, потом второй, потом опять первый и т.д.

Первый вариант самый лаконичный, второй самый корректный.
Во-во, такого ответа я и ждал. Другими словами, программист в коде обязательно должен будет задать попеременную обработку нужных блоков или присвоения нужного значения переменной. А для того, чтобы добавить / убрать фичу полосатости (клиенту не понравилось!) дизайнер должен будет отредактировать шаблон и обратиться к программисту, чтобы тот отредактировал программу, ага?
 
Сверху