Обсуждение статьи о шаблонизаторах

Фанат

oncle terrible
Команда форума
_RVK_
интересно посмотреть, как там у фаулера в оригинале.
может быть, ошибка перевода.
в одном месте написано "XML коду", причём здесь лово код можно толковать широко, в другом месте - " XML шаблона" и здесь уже двух смыслов быть не может - XML шаблоном быть не может по определению - это данные.
 

Gorynych

Посетитель PHP-Клуба
Прочитал с большим опозданием, но попробую добавить свои "десять центов".

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

Но, есть одно сильное но к статье в целом. На сколько мне понравилась первая половина статьи, настолько же мне не понравилась вторая. Я, честно, не уловил и не понял концовки и не понял ч кему хотел прийти в конце автор :-(

Что для меня кажется важным, достойным сильного акцентирования в статье?

1. Развенчание мифа о шаблонизаторах, как отделения логики представления.

2. Пояснение причин, заставивших все в свое время буквально помешаться на шаблонизаторах, потому что постоянное "этот код уже был написан", и потому, что изменение дизайна превращалось в кошмар.

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

Потому что это не поменять цвета, логотип и фамилию спонсора. Это, зачастую, полное перестроение внешнего представления. И вот тут поминали XSLT... Знаете, переписывать еще одну программу (это я об XSL, кстати), на довольно скверном языке... Увольте меня. Спасибо, нет.
 

denver

?>Скриптер
Gorynych
Хе-хе. Неохота превращать это в спор об XSL-панацее. Но шоб вы знали. Когда делаешь проект один, то хоть и без шаблонизатора всё сделай хоть с ним - всё равно гимору не избежать при редизайне.. Но когда проект делается не только тобой, но есть еще и верстальщик, то тут ты возможно и задумаешься (а может и нет) какого черта вы ОБА должны дергаться если изменился всего-лишь дизайн?
(я уж не говорю что этот подход очень полезен там где дизайн меняется чуть-ли не каждый месяц или для каждого заказчика. Это что-ж переписывать под каждого php код? гыыыыы)

ЗЫ. про сверность и т.п. поищите, много ли в инете плохих отзывов об XSL при всех его недостатках? Может ваши собственные разочарования лишь от недопонимания?
 

Фанат

oncle terrible
Команда форума
Rammstein
нельзя ли попросить сделать версию для печати?
в которой текст бы отображался чёрым на белом фоне, а не тёмно-серым на чёрном, и размер букв позволял разобрать их без микроскопа?
 

Фанат

oncle terrible
Команда форума
Вернёмся к статье. Фраза «Если вы четко разделяете PHP и логику представление то вы глубоко заблуждаетесь.» является спорной, если вы используете XML
разверни тезис.
грань настолько тонка, и при этом проходит настолько далеко от инструментов трансформации, а лежит в области формирования ДАННЫХ, что твои слова кажутся мне пустой болтовнёй.

Не секрет, что сортировать выборку удобнее средствами базы данных.
при этом ни "формат исходных данных" о котором ты говоришь, ни сами данные НЕ МЕНЯЮТСЯ. Только порядок.
кто должен делать сортировку?
а постраничный вывод кто должен делать?
не надо думать, что твой XSLT чем-то принципиально отличается от остальных шаблонизаторов.
 

Rammstein

PHPClub::News
Фанат
XML как источник данных относительно XSLT. Это не значит, что данные в этом XML и хранятся.

Постраничный вывод можно и с помощью XSLT реализовать, но это, имхо, изврат. К тому же, постраничная разбивка - это не логика представления (опять же ИМХО), потому как прежде всего, мы имеем дело с запросом пользователя (пользователь задаёт какую страницу он хочет видеть, сколько на ней записей и т.п.), к которому шаблонизатор касаться не должен.

_RVK_
Лишние проблемы на разные точки. Это скорее всего значит, что ты будешь верстать, писать JS и т.п. + скорее всего речи не идёт о какой-то платформе для разработки, а это == "Лишние проблемы на разные точки".
 

_RVK_

Новичок
Постраничный вывод это логика представления. Не сам вывод, а эта красивая панелька с циферками. И данные эта панелька получает из слоя домена - сколько страниц показать, какая текущая, сколько всего записей....
 

Фанат

oncle terrible
Команда форума
XML как источник данных относительно XSLT. Это не значит, что данные в этом XML и хранятся.
массив пхп как источник данных относительно пхп-шаблона. Это не значит, что данные в этом массиве и хранятся
ГДЕ РАЗНИЦА?

ГДЕ спорность утверждения в случае с XSLT?
ГДЕ доказательство того, что XSLT имеет хоть какие-то преимущества в рассматриваемом вопросе? разделения логики приложения и логики представления?
 

Rammstein

PHPClub::News
Фанат
А почему должна быть разница? Данные могут в этот массив или XML попасть из БД, а могут изначально храниться в этом виде (массив определяется в файле, а затем просто инклудится; xml сам по себе xml).
Своей фразой я хотел сказать, что если использовать XML и XSLT трансформации, мы не прибегаем к использованию PHP для преобразований (всё решается средствами XSLT). Т.е. тут как бы полностью получается отделить PHP от процесса трансформации (PHP нужно только инициализировать XSLT, загрузить таблицу стилей и предоставить исходники, а затем получить и вывести результат), фактически, мы не имеем механизмов влияния на ход трансформации, что не даёт нам возможности вклинить логику домена в шаблон.

-~{}~ 08.10.06 16:13:

_RVK_
Вопрос с этой панелькой достаточно сложный.
Наиболее правильным вариантом будет подход, когда мы передаём не параметры (сколько страниц показать, какая текущая, сколько всего записей), а структуру вроде:
[xml]
<pager>
<page num="1" current="0" />
<page num="2" current="0" />
<page num="3" current="0" />
<page num="4" current="1" />
<page num="5" current="0" />

<!-- А ещё лучше, добавить -->
<next_page num="5"/>
<prev_page num="3"/>
<!-- Добавлять в блок, если мы не на последней/первой странице соответственно -->
<last_page num="5"/>
<lfirst_page num="1"/>
</pager>
[/xml]
Но это, если придерживаться того принципа, что постраничный вывод не относится к логике отображения, т.к. имеет дело с запросом пользователя.
 

_RVK_

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

Эта грань между слоями тонка. О чем и сказанно в статье. А ты пытаешься прочертить толщенную границу. Ничего у тебя не выйдет.
 

Rammstein

PHPClub::News
_RVK_
Хм, я против хэлперов (точнее, не совсем "за"), а получение данных представлением из запроса влечёт проблемы с безопасностью. А если собираешься ещё и проверять данные в представлении, то это уже никакой не MVC.

Хэлперы лучше реализовывать как под-шаблоны (имхо, они этим и являются). Например, можно заставить XSLT переделывать
[xml]
<phone number="1234567" country="Russia" city="Moskow" />
[/xml]

в "+7 (495) 123-45-67". Вот это более чем правильно! (у лебедева в техногрете вроде по этому поводу что-то было).

Итого (моё мнение): хэлперы заменяем на подшаблоны (оно по определению так и есть), обращение к запросу из шаблона == дыра OR обращение к запросу из шаблона == верстальщик повешался из-за обилия проверок переменных из запроса.
 

_RVK_

Новичок
Кстати, продолжая дискусию о XSLT и представления с преобразованием. Вот что у Фаулера в оригинале:

The Transform View uses a transform style of program, the usual example is XSLT. This can be very
effective if you are working with domain data that is in XML format, or can easily be converted to
XML. An input controller picks the appropriate XSLT stylesheet and applies it to XML that's gleaned
from the model.


Так же отыскал в инете определение Фаулера о рпзличии между этими двумя видами логик:

"The key difference between Transform View and Template View is the way in which the view is organized. A Template View is organized around the output. A Transform View is organized around separate transforms for each kind of input element."

Имхо, расплывчатое определение.
 

Rammstein

PHPClub::News
Оч. расплывчатое (второе). Но это не различие между двумя логиками, а различие между двумя вариантами организации представления.
 

itprog

Cruftsman
много ли в инете плохих отзывов об XSL при всех его недостатках?
Конечно плохих мало, хороших много. Но почему-то все только языком чешут, примеров реализаций единицы.

Как бы битрикс уродственен внутри не был, но все же их опыту чуть-чуть можно довериться: _http://www.bitrixsoft.ru/blog/rsv/1.php
 

Rammstein

PHPClub::News
itprog
В XSLT ничего сложного (типа класс сделать). Вот, написано за 10 минут (наизусть DOM не знаю, сверяюсь с документацией)
Ещё есть class Model, но он только и делает, что преобразует В DOMDocument своё содержимое.
PHP:
<?php
/**
 * Возвожно, заведение конфигурационного файла для
 * шаблона (например, для автоматического включения
 * блоков в данные
 *
 * TODO Всё тут сделать
 */
class View
{
	private $xslt;
	private $source;
	
	public function __construct($view_name)
	{
		$this->xslt = new XSLTProcessor();
		$this->addTemplate($view_name);
	}
	
	public function addTemplate($name)
	{
		$doc = new DOMDocument;
		$tpl_file = VIEW_DIR."/$name.xsl";
		if(!file_exists($tpl_file))
			throw new ViewTemplateDoesNotExists();
		$doc->load($tpl_file);
		$this->xslt->importStylesheet($doc);
	}
	
	public function setModel(Model $model)
	{
		$this->source = $model->getDom();
	}
	
	public function render()
	{
		$res = $this->xslt->transformToDoc($this->source);
		return $res->saveXML();
	}
}

class ViewTemplateDoesNotExists extends DeveloperException 
{
	
}
?>
-~{}~ 09.10.06 13:12:

По поводу Битрикса. Такие выводы они могли получить из-за:
а) Архитектура битрикса гавно, отсутствие правильной реализации MVC.
б) Полное непонимание того, зачем нужен XSLT.

Вот это вообще бред:
"XSLT не дорос до полноценного языка программирования..."
Кто вообще сказал, что из XSLT пытались сделать язык программирования? CSS язык программирования??? ТУПИЗМ! Нахрена делать язык программирования, тогда как мы от этого мы и пытаемся избавиться?

"...на нем можно делать только простые условные представления и очень ограниченную логику."
Мысль не раскрыта, но думаю, им не хватает знаний в предметной области.
"Полная смена дизайна требует полного переписывания всех шаблонов, что в расчете на сложность создания XSLT получается еще дороже." А в ином случае это типа не требуется? Во-вторых, если все страницы однотипны (корпоративные порталы, например), то можно воспользоваться двухэтапной трансформацией, и нужно будет переписать только основной шаблон (если модель не меняется).

"базы преобразуются в XML (а это текстовый файл большого размера в силу своей архитектуры)"
Муахаха, фермеры, мля, а DOM на что? Нормальные люди всё это в файл не сохраняют (и потом загружают; так сказать, дурная голова ногам покоя не даёт).

"Специалистов по XSLT очень мало."
нормальный верстальщик должен знать XSLT, а не сотни вариантов синтаксиса шаблонизаторов.
 
Сверху