Применение шаблонов в случае XML\XSLT для "больших" порталов и не только

[eurolinedev]

Автор оригинала: Alexandre
Собственно, самого ажиатажа во круг ЦМС в области xml\xsl лично я не наблюдаю, да и Рекомендации W3C читать надо внимательней

Да, но я не писал, что W3C занимается спецификацией CMS... это скорее cmswatch.com и прочие с ними (но их стандарты, ествественно, никто в серьёз не принимает).

сам удивляюсь, и не раз задаю себе вопрос, а так же ни как не пойму почуму суета во круг ДотНета? Мода наверное.

Синдром НЕТ-озабоченности, ИМХО, не столько мода, как невероятно огромная финансовая стимуляция нарушения 2-го закона . По некоторым данным - с чьего-то блога из Майкрософт, суммарная приблизительная стоимость всего маркетингового проекта платформы .NET составляет больше половины стоимости всей Apple
В случае с Явой, стимулы кажется были иными...

Удел xml, Соответсвуя Рекомендациям W3C - это передача структурированной информации между разнородными приложениями, так сказать универсальный слой обмена Данными.

естественно, но в теории... Соответсвуя Рекомендациям
реально же, из всей этой абстракции, используется только SOAP (XML-RPC), ну и какие-то свои протоколы. А соотношения по частоте использования СОАП на порядки меньше использованию XML просто как конфигов... и вот в последнее время все эти "Valid XML" баннеры внизу страницы...
Вот поэтому я и задумался о переходе на xml-driven так сказать.

 

[Alexandre]

реально же, из всей этой абстракции, используется только SOAP (XML-RPC), ну и какие-то свои протоколы.

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

Одной из таких универсальных Спецификаций по передаче структурированной информации и является SOAP, который появился в September 13, 2000 (Creation of the XML Protocol Working Group).

Вообщето есть специальный орган OASIS(Организацией продвижения стандартов структурированной информации (the Organization for the Advancement of Structured Information Standards ) по ведению и упорядочиванию Стандартов и Спецификаций. Это так к слову... Посмотри сколько там опубликованно Стандартов и Спецификаций.

Если у нас в РФ (ну и на территории бывшего СНГ ) основная практика применения XML сводится к банальным конфигам, то это не значить, что так есть во всем мире.

В заключение, могу добавить, что обновления и обмен данными наиболее популярной часто используемой (а также всеми ругаемой ) учетной системой 1С устроен на базе XML. Также есть системы передачи XML данных между брокером и таможней, между Порталом приема заявлений от населения и распределения этой информации по адресатам. (это программа Казахстана Электронное правительство, сам участвовал в разработке стандартов). Так что, не только в WEB используется XML и не только для банальных конфигов.

 

[Voldar]

Давайте попробуем плясать от задач, которые ставятся перед шаблонизаторами. На мой взгляд их 2:

1. Вывод однотипных, повторяющихся блоков (например позиции каталога, новости, пункты меню etc.).
2. Поддержка "тем оформления".

Собственно связка xml+xslt эффективна для решения только первой задачи. Кроме того нужна хорошая система кеширования.

Теперь про "темы оформления". Здесь xml врядли будет эффективен. Соответственно те статические куски контента которые правит пользователь через WYSIWYG так и живут в html и не жужжат.

> и вот в последнее время все эти "Valid XML" баннеры внизу страницы
ИМХО вы путаете XHTML и XML. Баннер, "валидный XHTML" значит, что страница валидируется при помощи validator.w3.org без ошибок на соответствие стандарту XHTML. Соответственно шаблонизаторы к валидному xhtml-ю отношения не имеют, ну разве что Очень Кривой Шаблонизатор не позволит формировать валидные документы.

 

[slach]

Voldar
прекрасно XSLT справляется с темами оформления, вы просто не умеете их готовить =)

XSLT layout transformation + CSS ОЧЕНЬ мощный инструмент может получиться

вот как раз с выводом "БОЛЬШОГО" кол-ва (от 3000) повторяющихся блоков у XSLT не очень =)

 

[inTox]

вот как раз с выводом "БОЛЬШОГО" кол-ва (от 3000) повторяющихся блоков у XSLT не очень =)

Тут надо кеш. Вообще преобразования деревьев - дорогая операция по сравнению с реплейсом.

 

[Alexandre]

Тут надо кеш.

inTox, в моем случае кеш как раз и не катит, так как формируются разовые (раз в день ) длинные статистические таблицы.

когда я реализовывал всю эту кухню (именуемую биллингом), то в ТЗ ни чего не было на вывод больших объемов. Да и не прдпологались такие объемы. А когда пошли реальные испытания, то система просто встала - по 1-2 мин на запрос, из них около 30 сек составлял запрос в БД. После определения причины затыка, срочно пришлось переделывать вывод. Так что до 2000 строк в табл, вывод более менее нормальной, а вот с 3000 начинает глохнуть.

 

[Voldar]

2 slach

Возможно и справляется, просто как раз в районе тем у меня html с вызовами методо на все случаи жизни. Если сильно упрощенно:

<div id="header"><?php menu('topmenu'); ?></div>

И т.д. А уже menu('topmenu') отображает меню при помощи шаблона topmenu.xsl. Благодаря кешированию, дорогостоящее преобразование идет только по необходимости, когда меняли либо меню, либо шаблон. Получается очень хорошая экономия.

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

XSLT layout transformation + CSS - имеется ввиду XSLT преобразование на клиенте?

Alexandre

Так в этом случае XSLT явно лишний. Лично я бы при таких объемах даже не пробовал его применять.

 

[eurolinedev]

Приветствую!
Сперва, позвольте всех поздравить с Воскресением Христовым! Счастья и удачи!

Автор оригинала: Alexandre
Посмотри сколько там опубликованно Стандартов и Спецификаций.

Если у нас в РФ (ну и на территории бывшего СНГ ) основная практика применения XML сводится к банальным конфигам, то это не значить, что так есть во всем мире.

Alexandre, я посмотрел Ваш сайт (http://edocs.phpclub.net), безусловно, Вы тот человек, с которым бесполезно спорить о стандартах, но всё-таки, это моё (возможно не самое из удачных) ИМХО:
Да, на предметной областе "абстрактной прослойки при обмене данными", можно наспецифицировать невероятное множество стандартов и спецификаций, благо предметка позволяет...
однако, ИМХО, из всех этих стандартов, XML реально используется как "конфиги", соап, РСС-фиды и вот xml-based сайты... ктому же, сам XML позволяет нам самим создавать свои "стандарты" в рамках своих проектов, но такие стандарты будут использоваться только нами и только один (ну может, при удачной "идеи" несколько) раз, ровно как и все те стандарты "нашлёпанные" на XML другими организациями
...естественно пока... как Вы сами сказали, пока народ не созреет.
Но, в любом случае, не стоит использовать эти стандарты ради самих стандартов

Автор оригинала: Voldar

ИМХО вы путаете XHTML и XML.

Да, прошу прощения, непонятно написал... имелись ввиду баннеры CMS, внизу страницы сайта, на которой они (сайты работают)... например тот-же flux

All
Господа, возможно я повторюсь, но... предложение по-существу

Пересмотрев все выпуски PHPInside, я обратил внимание, что народ щедро делится своими познаниями в 2-х интересных мне областях - xml\xslt и Фреймвёрки.

Народ, было бы просто замечательно, если бы в одном из ближайших выпусков кто-то взял на себя труд, написать статью именно но "теории" проектирования именно xml\xslt CMS!

Безусловно, это та тема, котороая интересна многим, сейчас
И станет актуальна бля большего количества людей в скором будущем.

Спасибо за поддержание дискуссии, с уважением.

 

[Alexandre]

Так в этом случае XSLT явно лишний. Лично я бы при таких объемах даже не пробовал его применять.

Я бы тоже, как говорится "знал бы прикуп - жил бы в Сочи":

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

 

[inTox]

"теории" проектирования именно xml\xslt CMS!

вся эта теория, простите, представляет из себя то, что Вы подразумеваете под "НЕ xml\xslt CMS" + формирование xml и наложение xslt. То есть нет тут никакой теории. Есть правила построения шаблонов.
По сравнению с шаблонными движками и просто ПХП вы выносите обработку xml'я, сформированного скриптом в процессор xslt и показываете результат.
Таким образом вопросов немного:
"Как сформировать в пхп конкретные данные в xml, оптимальный для трансформации средствами xsl" или, с другой стороны слона: "как оптимизировать xsl таблицы для конкретных данных". Еще, пожалуй "кто будет писать xsl", но это вопрос скорее риторический.

 

[Voldar]

2 Alexandre

Ага, непредсказуемость - одна из самых забавных вещей в программировании .

inTox

Еще, пожалуй "кто будет писать xsl", но это вопрос скорее риторический.

Кстати, у меня в CMS-е я сделал один раз пару десятков шаблонов под разные задачи, и теперь в 80% случаев приходится просто заменять в них html, при этом все xsl-конструкции остаются нетронутыми.

eurolinedev

Вопрос тут, наверное, в том, что есть практический опыт работы, а вот с переложением его в теорию - проблемы. Я, например, хотя использую xml+xslt на коммерческих проектах с 2003 года ("играюсь" с 2002-го). 50+ готовых проектов плотно используют xml+xslt. Всю "теорию" могу уложить в 2 предложения:

1. Не стоит совать xml в каждую дырку.
2. Система кэширования на таких проектах - 90% успеха.

А вообще ИМХО всеобщее счастье наступит тогда, когда можно будет XSLT трансформацию на клиента переложить полностью. Т.е. отдавать XML+XSLT+CSS и забыть о проблемах. Но пока довольно велика доля браузеров, которые это не держат, это мечты или какие-то интранет, админки etc.

 

[Alexandre]

когда можно будет XSLT трансформацию на клиента переложить полностью

Voldar перекладывал я на плечи клиента XSLT трансформацию. Опять - та же кухня - на небольшие объемы это все работает на ура.

Для распространения этой технологии в массы необходима библиотека аля AJAX.
Технологию AJAX я использовал за долго до появления самого AJAX (я тогда имел смутное представление о шаблонизаторах). Но это было муторно писать яваскрипты, да и тогда - она работала только под ИЕ, по этому в 2001г-2002г мне пришлось от нее отказаться (как, например, и использование стандартного СОМ компонента TreeView).

Система кэширования на таких проектах - 90% успеха

С этим я согласен, кеширование необходимо все где есть частовызываемые страницы. Однако есть оборотная сторона медали - это организация чистки устаревшего кеша. Иногда кеш переполняется и это сильно замедляет работу (ну например когда в кеш-директории более 1500 файлов) Хочу заметить, что все индивидуально -все зависит от пректа.

 

[dimgel]

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

Примерно за год работы с XSLT (в таком же информационном вакууме - или я просто не там искал источники?) я пришел примерно к такой схеме (показываю в самой простой форме; прошу спецов прокомментировать):

1. Шаблон template.xml (общий для всех страниц):

<html>
    <head><title><my:include-content name="title"/></title></head>
    <body>
        <my:include-content name="menu"/>
        <hr/>
        <my:include-content name="page"/>
    </body>
</html>

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

<my:content>
    <my:block name="title">
        <my:param-value name="title"/> - <my:get-value name="id"> - Наш Сайтик!
    </my:block>
    <my:block name="menu">
       <div class="menu"><mymenu:spans rowset-name="main-menu"/></div>
    </my:block>
    <my:page>
         ....
         ....
    </my:page>
</my:content>

3. На вход XSLT кидается примерно такой файл:

<complex-input>
   <sys>
      <rootUrl>[url]http://...[/url]</rootUrl>
      <requestUri>...</requestUri>
      ...
   </sys>
   <get>... <!-- get-params --> </get>
   <post>... <!-- get-params --> </post>
   <template>common.xml</template>

   <param name="title">Hello world</param>
   ....
   <rowset name="main-menu">
       <r>
          <href>...</href>
          <title>hello cruel world</title>
       </r>
       .....
   </rowset>

   <input>
      <!-- А вот сюда втыкается содержимое шаблона страницы 
            products.xml, перед отдачей на вход XSLT. -->
   </input>
</complex-input>

 

[inTox]

Вот оно — зло.
Вы, вместо того чтобы преобразовать дерево в дерево, расставляете плейсхолдеры. Это ж вам не шаблоны, в самом деле.

Подумайте над этим:

index.xml - как вы формируете неважно, что то вставляете например из реквеста, что-то из базы, что-то из статического xml-файла

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="index.xsl"?>
<page name="title">
  <request>
    <param name="param_name">param value</param>
  </request>
  <content>
    <node-list>
      <node>data 1</node>
      <node>data 2</node>
      <node>data 3</node>
    </node-list>
  </content>
</page>

index.xsl

<?xml version="1.0"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<!-- импортируем некий общий файл с какими-то общими шаблонами-->
<xsl:import href="main.xsl"/>

<!-- переопределяем -->
<xsl:template match="content">
  <xsl:apply-templates />
</xsl:template>

<!-- общий шаблон для node, у которых родитель node-list -->
<!-- переопределяем -->
<xsl:template match="node-list/node">
  <b><xsl:value-of select="."/></b><br />
</xsl:template>

<!-- Шаблон для титла в зависимости от контекста (в данном случае если page/request/param/@name = 'param_name' -->
<!-- То есть пользуемся импортированным общим шаблоном, но в конкретном случае немного изменяем выдачу -->
<xsl:template match="page[request/param[@name='param_name']]/@title">
 Title — <xsl:value-of select="."/> - бла-бла-бла
</xsl:template>

main.xsl

<?xml version="1.0"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:template match="/">
  <html>
    <xsl:apply-templates select="page"/>
  </html>
</xsl:template>

<!-- Описываем HTML скелет страницы -->
<xsl:template match="page">
	<head>
		<title>
      <!-- Выводим  -->
			<xsl:apply-templates select="@title"/>
		</title>
  <head>
  <body>
   <!-- оформление -->
    <xsl:apply-templates select="content"/>
   <!-- оформление -->  
  </body>
</xsl:template>


<xsl:template match="content"><!-- заглушка например, ничего не выводим --></xsl:template>

<!-- Шаблон для титла в общем случае -->
<xsl:template match="page/@title">
 <xsl:value-of select="."/>
</xsl:template>

<!-- общий шаблон для node, у которых родитель node-list -->
<xsl:template match="node-list/node">
  <i><xsl:value-of select="."/></i><br /> 
</xsl:template>

Почувствуйте разницу, что называется. А есть еще ключи, сортировки, группировки и тьма всякой всячины...

 

[dimgel]

inTox: Спасибо, хоть кто-то мозги промыл... правда, я не уверен, что этого будет достаточно. Я частенько себя ловил на том, что начинаю надстраивать чуть ли не клон xslt над самим xslt. Действительно, мозги привыкли работать a la Smarty над PHP.

 

[Alexandre]

<html>
<head><title><my:include-content name="title"/></title></head>
<body>
<my:include-content name="menu"/>
<hr/>
<my:include-content name="page"/>
</body>
</html>

dimgel - name="page" это кто проставляет, наверно значениешаблона page должно быть разным для разных страниц, следовательно если значение аттрибута name формировать динамически (средствами РНР) - то это уже не сходится с концепцией шаблонов,
а следовательно должна быть изначально другая структура шаблонов.

-~{}~ 28.04.06 10:56:

Действительно, мозги привыкли работать a la Smarty над PHP

XSLT - совершенно иная идеалогия. Я написал статью "XSLT Шаблонизация" в пхпИнсайд(или найди в ине-те, клонов много), почитай и откроешь для себя много нового.

 

[inTox]

правда, я не уверен, что этого будет достаточно

Медитируйте над этим три раза в день до, после и вместо еды. =)
в догонку: http://www.dpawson.co.uk/xsl/index.html

-~{}~ 28.04.06 12:54:

если значение аттрибута name формировать динамически (средствами РНР) - то это уже не сходится с концепцией шаблонов

можно подробнее объяснить почему?

 

[Alexandre]

если значение аттрибута name формировать динамически (средствами РНР) - то это уже не сходится с концепцией шаблонов

можно подробнее объяснить почему?

шаблоны - на то они и шаблоны, чтоб по ним что-то формировать. А вот если мы будем формировать шаблон, а потом формировать что-то по шаблону - то это сродни масло-масленное. По этому, как сделать динамическое подцепление того или иного шаблона смотри в статье инсайда №9.

XSLT - совершенно иная идеалогия

здесь надо отойти от стереотипов мышления в плоскости смарти.

 

[dimgel]

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

<body l:file="products">
    ...
    <h3><l:localize id="h3"/></h3>
    ...
</body>

и

<body>
    ...
    <xsl:call-template name="localize">
        <xsl:with-param name="file" select="'product'"/>
        <xsl:with-param name="id" select="'id'"/>
    </xsl:call-template/>
    ...
</body>

Я догадываюсь, что:
(1) эта многословность многих допекает
(2) в данном случае я, наверное, тоже что-то делаю не так. У меня page localization files раскиданы по подкаталогам localize/en/... и имеют вид:

<localize>
    <item id="h3">products list (html can be used here)</item>
    ...
</localize>

Шаблон localize берет текущий язык из входного файла.

 

[slach]

<xsl:variable name="localize" select="document('localize/en/index.xml')/localize"/>

<h3><xsl:value-of select="$localize/item[@id='h3']"/></h3>

? ы ?