Forums / National / Russian / Шаблонизатор

<<<1234

Trustmaster
#46 2009-03-23 12:57
Ух, молодцы! Ещё бы сделали вложенные условия, парсер без многострочных регулярок, разбор условий без eval'а и оптимизировали использование памяти - я бы вам памятник поставил сразу :-)
May the Source be with you!
dervan
#47 2009-03-25 07:24
# Trustmaster : Ещё бы сделали ... разбор условий без eval'а

Хорошая мысль. :)

Пожалуй, совсем от варианта с eval() отказываться не надо - может потребоваться сложное условие. Но для простейших вариантов, когда в IF проверяется значение переменной bool или int, несложно сделать вариант без eval().

Мы с Dayver'ом, когда обсуждали разные варианты условий для IF (с вызовом функцищ, с использованием $GLOBALS для передачи аргументов функцищам), решили по возможности использовать в шаблонах для IF'ов не код PHP, а сформированные специально для шаблонов переменные bool. Именно такой подход использовал Dayver в выложенных им файлах, которые демонстрируют использование IF'ов в шаблонах.

Если придерживаться такого подхода и использовать в условиях IF шаблона только значения переменных bool или int, то эти условия будут проверяться без вызова eval().

Предлагаем улучшенный вариант XTemplate, проверяющий простые условия без eval(): xtemplate.class.php_57.zip
Остальные условия, которые не сводятся к простой проверке значения bool или int, как и прежде будут обрабатываться вызовом eval().

Все условия в выложенных Dayver'ом файлах этим вариантом XTemplate будут проверяться без eval(), т.е. будут обработаны быстрее.


Пример.

# Sergeich : В шаблоне page.tpl мне нужно разделять теги запятой (или любым другим разделителем), сейчас я это реализовал так:
<!-- BEGIN: PAGE_TAGS_ROW -->
	<a href="{PAGE_TAGS_ROW_URL}">{PAGE_TAGS_ROW_TAG}</a>,
<!-- END: PAGE_TAGS_ROW -->
Проблема в том, что после последнего тега также вставляется запятая (разделитель), что есть не красиво. Как бы убрать эту лишнюю запятую?

Если решать эту задачу, исходя из существующего кода плагина tags, получится вот что.

# dervan :
		<!-- BEGIN: PAGE_TAGS_ROW -->
		<a href="{PAGE_TAGS_ROW_URL}">{PAGE_TAGS_ROW_TAG}</a><!-- IF $GLOBALS['tag'] != $GLOBALS['tags'][count($GLOBALS['tags']) - 1] -->,<!-- ENDIF -->
		<!-- END: PAGE_TAGS_ROW -->
Только вот есть сомнения, правильно ли это - раз уж убирать HTML из кода, IMHO тогда не следует злоупотреблять кодом в шаблонах. А тут при каждом проходе парсера будет вызываться функцища count(). По-хорошему, в plugins/tags/tags.page.php надо добавить флажок, чтобы IF определял по нему последний проход парсера в блоке PAGE_TAGS_ROW.

Правильнее будет сформировать в plugins/tags/tags.page.php переменную для шаблона:
	$tags_cntdwn = count($tags);
	if($tags_cntdwn > 0)
	{
		foreach($tags as $tag)
		{
			$tags_cntdwn--;
и использовать в шаблоне простое условие:
		<!-- BEGIN: PAGE_TAGS_ROW -->
		<a href="{PAGE_TAGS_ROW_URL}">{PAGE_TAGS_ROW_TAG}</a><!-- IF {PHP.tags_cntdwn} -->,<!-- ENDIF -->
		<!-- END: PAGE_TAGS_ROW -->
При таком решении условие IF будет проверяться без eval(), и шаблон будет распарсен быстрее.
medar
#48 2009-03-25 17:59
dervan, dayver, супер, молодцы. :)
У меня, к сожалению, сейчас аврал на работе, времени для cotonti сейчас нет. Надеюсь скоро вернуться.

Предложенный вариант xtemplate, мне кажется, можно коммитить.

По поводу вложенности условий - сложно сказать, нужны ли они. Это будет провоцировать людей на программинг в шаблонах, а это все-таки лучше делать в плагинах.

По поводу eval(). В принципе, это дыра в безопасности, так как ушлый сторонний скинмейкер может разместить в условии кусок вредоносного кода. По хорошему надо бы от него совсем отказаться, сделав парсер условных выражений..
rangjungyeshe.ru
Macik
#49 2009-07-05 08:46
Наткнулся на обсуждение Xtemplate и решил оживить топик.

1. Не поддерживаю вашу инициативу по внесению логики в шаблоны в таком виде, по следующим причинам:
а. Логика должна быть в программной части, визуальная часть в шаблонах.
б. XTemplate сторонняя разработка и не есть гут ее "строгать" напильником, тем более, что в случае ее обновления будет трудно совмещать одно с другим.
в. Почти все (а может и все) можно реализовать за счет Callback функций - встроенного в XTemplate механизма. Причем без громоздких блочных IF-ENDIF конструкций в шаблоне.


2. В своем проекте наткнулся на баг XTemplate - при попытке переопределния tag_start_delim, tag_end_delim
перестают работать callback функции. Видимо где-то косяк с правилами и сочетанием RegExp. Но разобраться в коде не осилил.

Безотносительно написанного - спасибо вам за вашу работу. И развитие проекта.
https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F
Trustmaster
#50 2009-07-06 14:48
1. а. В целом согласен. А в частности бывают тонкости с отображением отдельных элементов, которые проще реализовать нехитрой логикой в шаблонах, чем делать хак ядра или писать отдельный плагин. Главное меру знать.
1. б. XTemplate развивается очень пассивно. Выше вероятность, что мы перепишем XTemplate, чем то, что выйдет новая версия с важными патчами, которые на придётся включать. Последнее не так уж страшно.
1. в. Опять же, callback-функции надо будет писать в виде специальных плагинов. И верстальщику непросто объяснить, что такое callback-функция.
May the Source be with you!
Macik
#51 2009-07-09 22:26
В общем согласен.
Хотя логика в блочном виде как сейчас не менее громоздка чем callback-функции.
Отдельного плагина на каждый случай не потребуется - достаточно описать класс с минимальным и достаточным набором callback функций.
Верстальщику вообще практически ничего объяснять не надо - надо показать 1 пример и все будет понятно.

Вот конкретика и примеры:
Вместо вот этого
<!-- IF {PAGE_DESC}== "" -->
Описание страницы пустое.
<!-- ENDIF -->

Можно будет писать так:
{PAGE_DESC|IS_NULL('Описание страницы пустое.')}

Все что нужно для этого - создать в системе дочерний класс:
class XT extends XTemplate {
  // функция проверки на предмет присвоено ли тэгу значение
  public function IS_NULL ($tag,$str) {
    // $tag - тело тэга с уже присвоеным значением
    // $str - строка, которую необходимо вывести если тег пустой
    if ($tag=='') {return $str;} else {return $tag;}
  }
}

Аналогичным образом можно реализовать любое другое условие.
Из плюсов такого подхода:
1. Мы не трогаем исходный класс;
2. Никаких отдельных плагинов - один раз описываем в системе класс и прописываем необходимую функциональность;
3. Экономим на размерах шаблона и соответственно меньше шансов допустить в шаблоне ошибку/опечатку.

Как дополнение:

В своем проекте пытаюсь реализовать "прозрачную" (более абстрактную) для верстальщиков систему интерфейса.

Сейчас по сути в шаблонах огромное количество HTML кода, и при том программно зависимого, как например:
<form action="{PAGEADD_FORM_SEND}" method="post" name="newpage" enctype="multipart/form-data">
...
<form>
в таком случае дизайнер/верстальщик должен знать что указать в параметрах action, mothod, name, и т.п.

Идея в том, что бы абстрагироваться от этого. Дизайнер указывает в шаблоне только ключевые Тэги:
<!-- BEGIN: MAIN -->
Форма регистрации:
{FORM_LOGIN}
<!-- END: MAIN -->
<!-- BEGIN: FORM_LOGIN -->
Введите свои данные:
Login: {INPUT_USER_LOG}
Password: {INPUT_USER_PASS}
{BUTTON_LOGIN_SEND}
{SOME_TEXT}
<!-- END: FORM_LOGIN -->

Задача программиста договориться с дизайнером о наборе тегов для конкретной формы.
Затем проинициализировать структуру данных, которая задаст парамертры конкретных элементов.
Далее вызвать автоматический обработчик, который уже на основании заполненых данных и на основании названия тегов решит что и как парсить.
https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F
This post was edited by Macik (2009-07-09 22:57, 14 years ago)
Sergeich
#52 2009-07-09 23:33
Macik, по поводу дополнения, собственно вы делаете обратную работу, одним из приоритетов в развитии котонти было вынесенеие всего хтмл из пхп-кода, плюс разбиение крупных тегов (несущих большой кусок хтмл) на мелкие составляющие. Это всё делалось для получения большего контроля за выводом информации посредством tpl. Разумеется это несколько усложнило шаблоны (хотя, скорее не усложнило, а увеличило кол-во чистого хтмл в шаблонах), но сильно подняло гибкость.

По поводу начала поста, а ваша конструкция сможет отрабатывать сложные куски хтмл с включением различных тегов движка? и будет ли это проще для дизайнера?
Macik
#53 2009-07-10 02:57
# Sergeich : Macik, по поводу дополнения, собственно вы делаете обратную работу, одним из приоритетов в развитии котонти было вынесенеие всего хтмл из пхп-кода, плюс разбиение крупных тегов (несущих большой кусок хтмл) на мелкие составляющие.
Видимо я не до конца донес мысль. Я не предлягаю переносить ХТМЛ в код, отнюдь. Наоборот из кода он пропадает практически полностью, т.к. все Тэги парсятся отдельной библиотекой, и уже она на основе внутренних шаблонов (тоже настраиваемых) создает готовый к работе ХТМЛ-тэг.
Примерно так:
Дизайнер пишет в шаблоне что-то типа:
 {INPUT_PASSWORD}
Программист пишет примерно следующее:
$ctl['Type'] = 'password';
$ctl['Name'] = 'rpassword';
$ctl['Class'] = '_default';
init_control('INPUT_PASSWORD',$ctl);
parse_control('INPUT_PASSWORD');
На выходе в шаблоне получаем готовый тэг:
<input type="password" class="password" name="rpassword" size="16" maxlength="32" />

В любом случае, это лишь касается моего проекта, так сказать мысли в слух, а не предложение или пожелание к движку.

# Sergeich : По поводу начала поста, а ваша конструкция сможет отрабатывать сложные куски хтмл с включением различных тегов движка? и будет ли это проще для дизайнера?
Да это вопрос. Я просто всегда иду со стороны того, что если не хватает функциональности - постарайся ее сделать доступными (читай предлагаемыми) методами и до последнего не залезать в "Core".
https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F

<<<1234