Xml, Xslt

LokiDi L0ck · August 26, 2008

Использует ли кто-нибудь в качестве основного шаблонизатора [xml-XSLT]?

Есть один вопрос.

ZoNT · August 26, 2008

Я не использую, но люблю каверзные вопросы. Если не знаю ответа, так хоть поищу (может нового чего узнаю)

LokiDi L0ck · August 26, 2008

Собственно ситуация.

Пишу cms в свободное время. Логику вида выполняют шаблонизаторы, которые можно свободно менять.

Логика вывода того или иного информационного блока лежит на плечах шаблона. Например где-нибудь снизу справа должен выводиться список определённых категорий:

<div>
	<p>Категории:</p>
	<ol>
		{cms:category id="5,6,7"}
			<li>
				<a href="{url}">{name}</a>
				{description}
				<hr>
			</li>
		{/cms:category}
	</ol>
</div>

Блок {cms:category} будет обработан шаблонизатором, где из базы будут вытянута необходимая информация по трём категориям и вставлена в шаблон блока три раза, для каждой категории соответственно.

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

Теперь я подумал, что неплохо было бы иметь возможность клепать шаблоны с помощью xml+xslt (и в таком ракурсе никогда с ними не работал).

Так как в моём представлении шаблон имеет право доставать и формировать информацию для вывода, тут появляется вопрос: чтобы вывести произвольные блоки, деревья и пр. информацию из базы в результирующий документ, нужно ли ВСЕ эти данные формировать в xml?

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

Чтобы xslt мог вытащить их например так:

<div>
	<p>Категории:</p>
	<ol>
		<xsl:apply-templates select="//category[@id=5 or @id=6 or @id=7]"/>
	</ol>					
</div>

...

<xsl:template match="category">
	<li>
		<a href="{url}"><xsl:value-of select="name"/></a>
		<xsl:value-of select="description"/>
		<hr/>
	</li>
</xsl:template>

А если я хочу вытащить два информационных блока (а их в базе 50 000)?

xslt'у необходим xml с этим списком, т.к. иначе он информацию получить не может. В итоге скорость не ахти.

Можно конечно воспользоваться XSLTProcessor::registerPHPFunctions и в xslt юзать php:function() и т.д. Но это пока не вариант.

Если же опираться на мнение, что шаблон не имеет права доставать произвольную информацию, а пользоваться только заранее для него сформированной (т.е. cms определяет, что надо выводить такойто шаблон, для которого можно сформировать xml с такимито категориями, такимито информационными блоками и меню), тогда конечно вопросов нет. Но и свободны так ГОРАЗДО меньше.

ZoNT · August 26, 2008

Всё правильно. Надо отдавать кусок xml (только нужный), а не всё-всё...

Ты же не отдаёшь все странички на запрос одной и не скрываешь(не отрисовываешь) ненужне. Логика та же. Надо отдавать только то, что просят, а как это отобразится и переконвертится в HTML - это уже будет задача XSLT.

LokiDi L0ck · August 26, 2008

Второй вариант не очень гибок в отношении управления информации самим шаблоном.

(Всё далее теория) Предположим пользователь зашёл на страницу: /monitors/lcd/dell-3008.html

Cms (после внутренней маршрутизации) определяет, что страница dell-3008.html ассоциирована со стилем monitor-detail.xsl
layout.xsl (схема сайта) подключает monitor-detail.xsl
Формируется xml с информацией по двум категориям (Мониторы (/monitors), Жидкокристаллические (/lcd)), о сайте (кодировка, описание и т.д.), каком-то конкретном меню, блоках (с id=5, 8) (которые должны выводиться только на данной страничке) и т.д.
На стороне сервера xslt трансформирует xml - получаем результирующий документ.

Теперь, представим, что понадобилось выводить другие блоки (с id=1, 9). Для этого придётся править логику в скрипте формирующем xml (в пункте 3) (а в случае с типичным php-шаблонизатором - в шаблоне можно было бы просто поменять id).

Собственно, мне не очень импонирует невозможность извлечения произвольных данных ИЗ шаблона, т.к. с практической точки зрения (о xml, xslt) - пользователь помимо работы с шаблоном должен будет также работать и с скриптом, формирующем xml (а это лишние затраты на рабочие руки)

ZoNT · August 26, 2008

1) от пользователя идёт запрос на сервер: дай мне страничку /monitors/lcd/dell-3008.html и мониторы с 1-го по 20 (по порядку). Я сижу в ИЕ.

2) Серверный скрипт отдаёт XML (мониторы с 1-го по 20-й из базы) и всё!

3) Серверный скритп отдаёт XSLT для ИЕ.

4) xml и xslt загружаются в браузер и xslt из xml формирует html.

Снова:

1) от пользователя идёт запрос на сервер: дай мне страничку /monitors/lcd/dell-3008.html и мониторы с 1-го по 20 (по порядку). Я сижу с мобилки.

2) Серверный скрипт отдаёт XML (мониторы с 1-го по 20-й из базы) и всё! Он отдаёт тот же самый XML, что и впревом случае!!!

3) Серверный скритп отдаёт XSLT для мобилки.

4) xml и xslt загружаются в браузер мобилки и xslt из xml формирует html для мобилки.

И так далее. Таким образом, скрипт отающий XML всегда неизменен и ему наплевать, как там обработают этот XML (и кто).

А разным отображением инфы занимается XSLT-шаблон. И для разных устройств/браузеров можно наделать шаблонов до усраки. А можно наделать шаблонов для одно страницы и хранить идентификатор шаблона в куках. Таким образом один шаблон - один скин для странички .

LokiDi L0ck · August 26, 2008

ZoNT, вы меня не поняли

Моя основная мысль:

1) Програмные шаблонизаторы (ПШ) позволяют вытаскивать произвольную информацию и обрабатывать её на месте (см. пример с {cms:category}).

2) XML+XSLT: зависит от логики формирующего XML СКРИПТА.

Представьте, что на monitors.html всегда выводилось по 20 мониторов и больше ничего, т.е. СКРИПТ брал из базы 20 записей, формировал их в xml и отдавал на съедение xsl.

Через некоторое время мы решили, что на monitors.html необходимо справа разместить список 3ёх самых раскупаемых мониторов.

Это значит, что мы должны:

a) Изменить СКРИПТ (Он помимо 20 записей, теперь достаёт ещё 3, и формирует XML с новыми тремя элементами.)

Изменить .XSL файл (написать соответствующий <xls:template> для обработки новых 3 элементов)

Теперь вернёмся к 1-ой мысли. Если бы мы пользовались ПШ, то нам было бы достаточно изменить сам шаблон - и всё.

Что-нибудь вроде:

До изменения:

<div>
Мониторы:
<ol>
{cms:section id="monitors"}
	 <li>{title} - {model}</li>
{/cms:section}
</ol>
</div>

После добавления трёх популярных:

<div style="width:50%; float: left;">
Мониторы:
<ol>
	{cms:section id="monitors"}
		<li>{title} - {model}</li>
	{/cms:section}
</ol>
</div>

<div  style="width:50%;">
Популярные:
<ol>
	{cms:section id="monitors" count="3" order="sale_number"}
		<li>{title} - {model}</li>
	{/cms:section}
</ol>
</div>

Видите разницу? В случае xml+xslt помимо работы c .xsl, придёться работать и со скриптом.

Иван Шумов · August 26, 2008

LokiDi L0ck, а ты в курсе что XSLT - довольно медленная технология?

LokiDi L0ck · August 26, 2008

LokiDi L0ck, а ты в курсе что XSLT - довольно медленная технология?

В курсе.

Как и в том, что это не имеет к теме никакого отношения

ZoNT · August 26, 2008

XSLT занмается только обработкой XML!!! Поэтому при смене увеличении задачи тебе придётся дописать еще один темплейт + получить нужный xml (а это изменение серверной части).

А шаблон cms позволит сделать всего одну операцию, но на выходе ты получишь всегда один и тот же html!

XSLT нужен для других целей: мы получаем от серверного скрипта всегда XML и используем его как нам угодно (пишем джава-апплет для мобилок, не имеющих браузера, пишем просто прогу, анпример экранную заставку, которая отображает текущий курс валют) и если нам надо этот XML преобразовать в HTML (а можно и в другой XML - XSLT это тоже делает), то используем XSLT.

Yarik Voronov · August 26, 2008

2 LokiDi L0ck. следует отметить, что xslt шаблон не обязательно должен содержать форматирование ВСЕЙ страницы.

Что такое шаблонизатор? это шаблон + парсер этого шаблона, который обеспечивает функционал этого самого шаблона. если парсер шаблона не поймет эту строку {cms:section id="monitors" count="3" order="sale_number"} то тоже надо будет лезть в его движок и дописывать функционал, т.е. менять скрипт. Шаблонизатор хорош тем, что кто-то хороший уже продумал его функционал и его шаблон. т.е прописал как парсер должен реагировать на ключевые слова.

Если брать xml+xsl то в свете приведенного примера (с топ 3 мониторами) я вижу усложнение логики: у нас есть (должна бы быть) матрица конечной страницы. в этой матрице прописано какой запрос, какой xml каким xsl шаблоном следует обработать. т.е. конечная страница - это есть набор маленких xml распарсенных нужным xsl и собранных вместе согласно очередности (и логики) прописанной в матрице. В Програмном шаблонизаторе то что я назвал матрицей, уже прописано в шаблоне вот и все. А XSLT, как заменил ZoNT, нужен для других целей...

...XSLT, which is a language for transforming XML documents into other XML documents

Итак, на сервере можно парсить множество мелких xml, а можно собрать один xml файл и один xsl-шаблон для этого файла. Имхо, это уже вопрос удобства и целесообразности. Под мелкими xml я подразумеваю: xml для меню, для хедера, для футера, для основной части, для какого-нибудь блока опроса-вопроса, статистики ну и т.д.

LokiDi L0ck · August 26, 2008

у нас есть (должна бы быть) матрица конечной страницы. в этой матрице прописано какой запрос, какой xml каким xsl шаблоном следует обработать. т.е. конечная страница - это есть набор маленких xml распарсенных нужным xsl

Yarik Voronov, всё прекрасно понимаю и прежде чем писать свой первый пост не раз уже обдумывал различные варианты. И как бы там нибыло, работать с формирующим xml документ скриптом так или иначе работать всё равно придёться.

XSLT нужен для других целей

ZoNT, согласен. Потому и пояснил в первых постах:

и в таком ракурсе никогда с ними не работал

Всем остальным движет только интерес к эксперименту.

Yarik Voronov · August 27, 2008

И как бы там нибыло, работать с формирующим xml документ скриптом так или иначе работать всё равно придёться.

Конечно придется. Просто логика будет иная. Я хочу сказать что при сравнении в посте №7 следовало бы исходить из того что ни ПШ ни Xml система "не знают" как сформировать топ 3 на странице monitors.html Это конечно чистая софистика, но чтобы "почуствовать разницу" надо поставить объекты сравнения в равные условия, но применить к ним разные методы. Почему то мы забыли что и в случае с ПШ надо будет работать с формирующим array массив исходных данных скриптом и со скриптом шаблона, дописывая недостающий функционал.

Имхо. я не виже слишком большой разницы в смысле применения двух разных подходов. Разница лишь заключается в том что используются различные инструменты и соответственно различна и логика (алгоритмы) их применения.

Хочу еще раз повториться: xsl шаблон не обязательно должен содержать форматирование всей страницы, как и xml файл не обязательно должен быть монолитным (полученным в одном и только одном скрипте).

Например monitors.mtz ("матрица")

<!DYNAMIC VARS [%style% GETFROM "preferencies.php" ]>

Придумано за пять минуть ничего нисчем общего не имеет - просто так бы я например решал задачу CMS на технологии xml+xsl.

Имхо логически запись :

ничем не отличается от записи:

{cms:section id="monitors" count="3" order="sale_number"}<li>{title} - {model}</li>{/cms:section}

и в первом и во втором случае происходит замена сущностей сгенерированным контентом.

Yarik Voronov · August 27, 2008

С другой стороны никто не мешает применить "знакомые буквы"

monitors.mtz (пример чисто теоретический)

{cms:section id="monitors"}
	   {cms:xtemplate name="Мониторы" type="div-ol-li"}
			{title}-{model}
	   {/cms:xtemplate}
{/cms:section}
{cms:section id="popular" count="3" order="sale_number"}
		{cms:xtemplate name="Популярные" type="custom"}
			 <div id="{&&cms:section:id;}"><p>{&name;}</p>
				 <ol>
					<xsl:apply-templates />
				 </ol>					
			 </div>
			<xsl:template match="monitor">
				<li>
				  <a href="<xsl:value-of select="@url"/>"><xsl:value-of select="@name"/></a>
				  <xsl:value-of select="."/><hr/>
				</li>
			</xsl:template>		   
		{/cms:xtemplate}
{/cms:section}

то есть логика такова, что как только матрица попадает в парсер. парсер "решает" какой скрипт, формирующий нужный xml подключить и каким xsl этот xml обработать: либо уже имеющимся в наборе (type="div-ol-li") или произвольным (type="custom"). Собственно разницы с обычным ПШ особой нет. Если раньше мы получали тип данных php array() например, то теперь получаем тип данных xml от скрипта. Если раньше мы брали уже готовый html-шаблон c внедренными сущностями cms, то теперь придется прописывать этот html-шаблон через xsl.

Т.о. получаем еще одно промежуточное звено в алгоритме, а именно: какой xsl шаблон применить в зависимости от... (типа устройства, выбранной темы и т.п.). C одной стороны преимущество, с другой усложнение кода и верстки.

Я думаю ничего нового для вас не сказал, но все же хотел высказаться.

Yarik Voronov · August 27, 2008

PS. И последнее размышление. если учитывать, что

XHTML family document types are XML based, and ultimately are designed to work in conjunction with XML-based user agents

То бишь XHTML - это тот же XML. То пусть ПШ клепает страницы как клепал, единственное требование к нему чтобы клепал в XHTML Strict. имхо, мы можем взять такой выходной документ написать к нему шаблон xsl и превратить этот выходной документ в любой другой, даже того же типа, но другого форматирования. Собственно тогда "пользователь помимо работы с шаблоном" уже не "должен будет также работать и со скриптом, формирующем xml", пользователь должен будет по собственной необходимости и инициативе писать xsl-стили трансформации для исходного шаблона (документа XHTML). Как говорил один йог:"Теперь свободы завались... На вот возьми долото и молоток и начни ей придавать конкретные формы"

PPS. Я ничего не хочу доказать и никого не стараюсь обидеть. Я понимаю и принимаю, что в каких-то местах мог противоречить сам себе, повторять уже сказаное и сказаное не мной. Я всего лишь решал задачу: "возможности извлечения произвольных данных из шаблона по технологии xml + xsl"

LokiDi L0ck · August 28, 2008

С другой стороны никто не мешает применить "знакомые буквы" (IMG:style_emoticons/default/smile.gif)
monitors.mtz (пример чисто теоретический)

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

То бишь XHTML - это тот же XML

А то

То пусть ПШ клепает страницы как клепал, единственное требование к нему чтобы клепал в XHTML Strict. имхо, мы можем взять такой выходной документ написать к нему шаблон xsl и превратить этот выходной документ в любой другой, даже того же типа, но другого форматирования.

Это больше похоже на следствие формирования результирующего документа - управление только его видом.

А в идее с:

Например monitors.mtz ("матрица")
<!DYNAMIC VARS [%style% GETFROM "preferencies.php" ]>
<BLOCK head XSL="{!style/head.xsl}" ENGINE="modulas/xGetHead.php" />
<BLOCK top CHOOSE="3" CRITERIA="{topOfSales}" XSL="{!style/senterTop.xsl}" ENGINE="modulas/xGetTops.php" />
<BLOCK content CHOOSE="20" CRITERIA="{$_GET['monitor-type']}" XSL="{!style/senterContent.xsl}" ENGINE="modulas/xGetContent.php" />

что-то есть

Sign In

Xml, Xslt

Question

Link to comment

Share on other sites

15 answers to this question

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Обсуждения

Important Information