Все согласны с этим утверждением?

У меня сомнения в необходимости индексации комментариев.
Кроме того, я хотя и не специалист в web-разработках, но совершенно не понимаю, в чем там может быть проблема. Наоборот, дают чистый XML, без всякого левого оформления. Индексируй сколько хочешь.

))))) Изучите, пожалуйста, XSLT, а потом предлагайте.

1. Они не индексируються, можете послушать доклад с РИТ2007 на эту тему, я дам ссылку. Там это решают серверными средствами, которые нам не доступны
2. Опять появиться проблемма вставки данных, те чтобы обработать шаблон нужно:
- Получить данные с БД
- Обработать
- Преобразовать в XML
- Трансформировать при помощи XSLT
- Сохранить в HTML

Потом для вставки комментариев:
- Получить данные с БД
- Обработать
- Преобразовать в XML
- Трансформировать при помощи XSLT
- Вставить в HTML страницы
- Сохранить HTML

При этом нельзя разбавить 1 страницу 2 частями, те отдать комментарии в XML'e и каждый раз нужно будет обработывать не маленький файл HTML, в котором нужно будет найти начало и конец комментариев и вставлять туда данные.

1. SEO мне неинтересен, поэтому ссылок не надо.
Просто я не вижу технических препятствий для индексации XML. Скорее наоборот, XML проще анализировать и фиксировать в БД поисковика.

2. Первые три пункта (получение, обработка, преобразование в XML) вполне можно объединить в один. Четвертый делать на клиенте, после чего пятый не потребуется.

Насчет вставки комментариев не понял.

Цитата:

Изучите, пожалуйста, XSLT, а потом предлагайте.

Я снова объясняю то, о чём мы уже говорили.

Цитата:

Первые три пункта (получение, обработка, преобразование в XML) вполне можно объединить в один

Какая разница?
В любом случае этап преобразования в XML жрёт ну очень много памяти, в частности это массивный благодаря своей структуры файл который потом ещё раз увеличиваеться для нормальной работы XPath

Цитата:

Четвертый делать на клиенте

Трансформировать на клиенте НЕЛЬЗЯ. Поисковые роботы минуя всю простоту разбора XML'a его не понимают

Цитата:

пятый не потребуется.

Значит кеш будет работать на XML'e

Цитата:

Насчет вставки комментариев не понял.

А как вы их вставите в уже сгенерированую страницу иначе?
Лежит ШТМЛка с предыдущей трансформации, пользователь добавил комментарий, его нужно внести в шаблон. Для этого нужно или полностью обновить кеш страницы, или в существующий вставить комментарий.

Цитата:

SEO мне неинтересен, поэтому ссылок не надо.

РИТ это не SEO

Выскажу пожалуй свои соображения.

1) Можно частично переложить преобразование на клиента.
Поисковикам совершенно не интересна админка - поэтому отдаем её в XML (так например в umi сделано)

2) Кто мешает использовать 2 уровневый кеш?
- уровень 1: кешируем XML
- уровень 2: кешируем результаты преобразования

Тут правда сложности с синхронизацией возникнут.

3) В уже сгенерированную страницу можно вставлять части следующим образом

Шаблоне пишем к примеру:

<xsl:value-of select="php:function('php_get_contents',<параметры>)"/>

Сама функция может работать каким угодно образом:
- вернуть просто текст
- вернуть html (предположим из кеша)
- вернуть результат другого XSLT преобразования (можно и из кеша)

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

4) По поводу
Цитата:

- Получить данные с БД
- Обработать
- Преобразовать в XML

Тут, как мне кажется будет очень кстати использовать базы отдающие результат сразу в XML.
Честно скажу, сам не пробовал. Хотя недостатки у способа конечно есть (особенно сложности с обработкой).

5) Вместо bb и html в комментариях лучше использовать xml
Т.е. пользователи должны вместо кодов вставлять xml теги
В этом случае для постов пользователей нет необходимости в обработке и можно использовать все преимущества 4 пункта.

Если посмотреть глубже у нас получается 2 уровневая система шаблонизации, на первом уровне генерация XML (может смарти приспособить? ), на втором - HTML. Единственный плюс заключается в том что можно из 1 xml документа получить много разных (и не обязательно в HTML).

Не маловажный вопрос: а кто будет XSLT шаблоны писать?

Цитата:

1) Можно частично переложить преобразование на клиента.

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

Цитата:

2) Кто мешает использовать 2 уровневый кеш?
- уровень 1: кешируем XML
- уровень 2: кешируем результаты преобразования

Тут правда сложности с синхронизацией возникнут.

Зачем? на получение XML'a нужно где-то 0,08-0,1 сек. + запросы будут кешироваться и так...

Цитата:

<xsl:value-of select="php:function('php_get_contents',<параметры>"/>

Включать в XSLT пхп функции не рекомендуеться

Цитата:

Тут, как мне кажется будет очень кстати использовать базы отдающие результат сразу в XML.

И этот XML всё-равно нужно обработать + изощраться к требованияк КМС к системме (не каждый хостинг позволит, хотя я не пробовал, не уверен...)

Цитата:

5) Вместо bb и html в комментариях лучше использовать xml

Извините, но это бред. Преобразование в HTML идёт лишь 1 раз при добавлении

Цитата:

может смарти приспособить?

Ещё больший бред, мы тут от смарти стараемся избавиться. В пхп масса екстеншинов для работы с XML, можно также строить через DOM

Цитата:

а кто будет XSLT шаблоны писать?

Верстальщик, знающий XSLT или я Не зря же я его изучаю


В целом ваши предложеня не решили не 1 с моих проблемм должным обзазом (, но спасибо за попытку помочь

Цитата:

Включать в XSLT пхп функции не рекомендуеться

Как хотите, если вам удобно постоянно преобразовывать весь XML документ, вместо того чтобы преобразовывать только измененные части.

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

Правда в этом случае клиенту отдать xml уже не получится (хотя мне кажется что можно обойти эту проблему).

Цитата:

Извините, но это бред. Преобразование в HTML идёт лишь 1 раз при добавлении

Почему же бред? Если хранить комменты в XML к ним тоже можно будет применять XSLT и не надо дополнительного парсера (как в случае с bb кодом). И это наиболее гибкий вариант. Если вы будите использовать html для хранения комментов - какой тогда смысл использовать xml в других местах?

Цитата:

Зачем? на получение XML'a нужно где-то 0,08-0,1 сек. + запросы будут кешироваться и так...

Да не много, а если учесть что практически все блоки на странице будут каждый раз одни и теже? Получается что большая часть времени тратится зря.

Цитата:

В пхп масса екстеншинов для работы с XML, можно также строить через DOM

Да можно, но удобно ли? и какова будет скорость?

По поводу клиента - можно определить бот это или нет, боту отдаем полноценную html страницу, а пользователю xml+xslt.

Долго печатал ответ и стёр. Понял что мне тут ничем не помогут, разве-что уйдёт куча времени чтобы всем всё доказывать))))
Кратко... Спорить по поводу совего мнения, пока не покажут что-то с личного опыта... Я уже очень много вариантов перебрал и получаеться, что всё-равно каждый останеться при своём мнении...

LastDragon, вы вот предлагаете всё это. А вы насколько хорошо знаете о чём говорите? Вы делали хоть 1 высоконагрузочный проект с XSLT на PHP?


Последний раз...

Цитата:

Да можно, но удобно ли? и какова будет скорость?

Ну да, смарти для создания ХМЛа будет намного быстрее, чем ексеншены и DOM (тема закрыта)

Цитата:

По поводу клиента - можно определить бот это или нет, боту отдаем полноценную html страницу, а пользователю xml+xslt.

Боты поисковых системм маскируються иногда, чтобы проверить на лживость ресурсов. За такое вроде забанят сразу-же тк все должны получать одинаковый результат.
Вообще это предлагалось на РИТ2007, только там был проксирующий сервер. На пхп это реализовать особого смысла не вижу.

Цитата:

Почему же бред? Если хранить комменты в XML к ним тоже можно будет применять XSLT и не надо дополнительного парсера (как в случае с bb кодом). И это наиболее гибкий вариант. Если вы будите использовать html для хранения комментов - какой тогда смысл использовать xml в других местах?

не вижу связи между комментариями и шаблонизатором. Хотите лишние преобразования добавить и каждый раз ещё и структуру комментария ХСЛТ обрабатывать? Я - нет. На эту тему говорить больше не буду.

Цитата:

Да не много, а если учесть что практически все блоки на странице будут каждый раз одни и теже? Получается что большая часть времени тратится зря.

Это делает системма кеша модулей. И кто сказал что блоки будут одинаковы? И какая это большая часть времени? Зачем я полный кеш пытаюсь сделать? Именно чтобы не нужно было собирать по кусочкам все маленькие кеши и выполнять трансформацию, а иметь уже готовую страницу. Полностраничный кеш будет обновляться редко и время на обновление просто мизер. Можно будет его подргружать вовсе без учавствия PHP. Подумайт сами... (тема закрыта)

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

Про смарти я шутил с мамого начала .

Цитата:

А вы насколько хорошо знаете о чём говорите? Вы делали хоть 1 высоконагрузочный проект с XSLT на PHP?

Сам большой фанат xml и xslt , тоже пытался шаблонизатор сделать, НО когда время генерации практически пустой (обрабатывалась только структура ну и пару строк текста) страницы (без кеширования) приблизилось к 0.2сек, решил его не доделывать... (точнее отложил в дальний ящик ) Хотя должен признать, что (а) тачка была медленная сама по себе (G4 700 МГц); (б) - было много лишних действий; и наконец (в) - при использовании xslt вылазит целый ряд проблем, которые я здесь уже перечислял ссылка.

Цитата:

PHP в XSLT вставлять не буду, считаю это плохой идеей

Точно такого же результата можно добиться используя xslt doсument() и враперы для потоков (работать и на клиенте будет).

Всеже у меня есть несколько вопросов:
1) Ваш шаблонизатор будет обрабатывать только структуру страницы (т.е. данные (теже комменты) уже лежат в готовом html виде и не участвуют в преобразовании)?
2) Подскажите решение вот такой задачки: у меня есть xslt шаблон который импортирует 20 других шаблонов, но для генерации одной страницы мне надо всего 5 шаблонов, для второй другие 10 шаблонов (эти страницы содержат разные наборы узлов)... как исключить загрузку ненужных данной странице шаблонов?

Цитата:

Ваш шаблонизатор будет обрабатывать только структуру страницы (т.е. данные (теже комменты) уже лежат в готовом html виде и не участвуют в преобразовании)?

Не совсем понял вопрос

Цитата:

у меня есть xslt шаблон который импортирует 20 других шаблонов, но для генерации одной страницы мне надо всего 5 шаблонов, для второй другие 10 шаблонов (эти страницы содержат разные наборы узлов)... как исключить загрузку ненужных данной странице шаблонов?

кхм... кхм... Я с такой проблеммой не сталкивался, но думаю у вас там что-то не правильно, раз используеться такое количество файлов и подгружаемые нужно выбирать прямо в XSLT Архитектуру приложения можно изменить для большей удобности?

Цитата:

2) Проблемы с выводом сущностей (&nbsp; и тд)
Все HTML сущности надо объявлять перед использованием, но даже после этого в конечном документе они будут представлены в виде юникода...

DTD для таких случаев вроде можно заюзать

Цитата:

DTD для таких случаев вроде можно заюзать

Можно, но просто перечислить сущности не получится, в этом случае в итоговое дерево будут подставляться значение сущности, т.е. вместо &nbsp; у нас будет U+00A0. Если кодировка UTF-8 то все вроде нормально (именно вроде), но если используется 1 байтная кодировка - на выходе мы получаем эти же 2 байта.

Одно хорошо решить эту проблему можно и с помощью disable-output-escaping.
Была идея как с помощью DTD подправить, но писать не буду т.к. сам не проверял её работоспособность.

А вы еще не сталкивались с проблемой обработки DTD в php? Посмотрите как это сделано и насколько удобно это использовать , не говоря о наличии багов... (я с одним сталкивался, но впечатление это подпортило сильно). В xsl файлах еще ладно, но когда возникает необходимость в сущностях внутри генерируемого xml файла проблема проявляется особенно заметно (тут эта бага и вылазит).
(Я очень надеюсь что эту ошибку исправили.)

Цитата:

Я с такой проблемой не сталкивался, но думаю у вас там что-то не правильно, раз используеться такое количество файлов и подгружаемые нужно выбирать прямо в XSLT Архитектуру приложения можно изменить для большей удобности?

Проиллюстрирую на примере (возможны опечатки):

Пусть есть xslt файл (это главный файл шаблона, он одинаков для всех страниц):

<?xml version="1.0" encoding="UTF-8"?>

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

<xsl:param name="title">Тест</xsl:param>

<xsl:output method="html" encoding="utf-8" indent="yes"/>

<!-- Подключаем используемые стили -->

<xsl:include href="error.xsl"/>

<xsl:include href="content.xsl"/>

<xsl:include href="forms.xsl"/>

<!-- ... другие файлы ... -->

<!--

- Чем больше и сложнее шаблон, тем больше список

- Естественно сами импортируемые стили тоже содержат xsl:include

- Самое важное - xsl:include и xsl:import это top-level-element!

- Т.е. больше нигде их использовать нельзя :( из за этого все проблемы...

-->

<xsl:template match="rootelem">

<html>

<head>

<style><xsl:comment>

<!-- тоже показательно - вам удобно писать в таком виде? -->

</xsl:comment></style>

</head>

<body>

<!-- здесь обработка нужных узлов -->

<xsl:apply-templates/>

</body>

</html>

</xsl:template>

</xsl:stylesheet>

(с пробелами тут проблема....)

Вроде все нормально, теперь мы обработаем такой документ:

<?xml version="1.0" encoding="UTF-8"?>

<rootelem>

<contents>

<!--

- Большой блок xml данных

- Для обработки необходим content.xsl

-->

</contents>

</rootelem>

Что в итоге - 2 файла стилей нам не нужны (error.xsl и forms.xsl), однако они будут загружены и преобразованы в DOM. Поставить условие на их загрузку невозможно (как меня это разочаровало не передать ). И чем больше и сложнее шаблоны, тем больше будет копится неиспользуемых файлов стилей. Как думаете быстро это будет работать?

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

Цитата:

не вижу связи между комментариями и шаблонизатором. Хотите лишние преобразования добавить и каждый раз ещё и структуру комментария ХСЛТ обрабатывать? Я - нет. На эту тему говорить больше не буду.

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

Скажите а какую пользу вы расчитываете получить от использования XSLT?

Еще одна заморочка - необходимо следить за валидностью xslt и генерируемых xml фалов, если возникнет ошибка - шаблонизатор умрет...

С экономической точки зрения - на сколько больше будет стоить верста такого xslt макета?
(особенно если судить по этой теме получается, что людей которые что-то знают о xslt не так уж много)

Цитата:

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

Средствами php через DOM каждый раз указывать какие файлы подгружать - первое, что пришло на ум

Цитата:

Еще одна заморочка - необходимо следить за валидностью xslt и генерируемых xml фалов, если возникнет ошибка - шаблонизатор умрет...

Там можно сделать по-другому. По памяти <!С экономической точки зрения - на сколько больше будет стоить верста такого xslt макета?
Я ещё в стадии изучения и оценивать не берусь

Цитата:

Средствами php через DOM каждый раз указывать какие файлы подгружать - первое, что пришло на ум

Редактировать шаблоны в самом скрипте? тут по моему еще больше сложностей чем с php:function и xslt функцией document().

Цитата:

Там можно сделать по-другому.

Да можно, но какой тогда смысл использовать XSLT если внутри все уже жестко задано?

Цитата:

Да можно, но какой тогда смысл использовать XSLT если внутри все уже жестко задано?

Шаблонизация, замена смарти-подобного

Цитата:

Редактировать шаблоны в самом скрипте? тут по моему еще больше сложностей чем с php:function и xslt функцией document().

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

Цитата:

Шаблонизация, замена смарти-подобного

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

Цитата:

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

Дело не в том тяжело или нет. Для чего нужен шаблонизатор - для отделения логики от представления. так? при использовании предложенного вами подхода получится что представление связано с логикой (не совсем верно) + используется тормознутое представление.....

Можно конечно чтобы все связи шаблонизатор отслеживал, но это еще медленнее получится....

Как вы себе все это представляете?
У шаблонизатора есть список всех стилей которые требуются текущей странице? (можно конечно - если страниц все пару штук, а если их сотни?)

По моему это в корне неверный подход.

Еще один минус - нельзя выполнять обработку импортируемых в шаблоне стилей.

А вы задумывались как подключить к xslt шаблону вывод модуля (а он предположим использует только свои стили)?

Цитата:

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

Хм, мне особенно нравиться в ХСЛТ то, что данные можно вывести в любом формате: рсс ленту, принт-френдли страницу, ртф документ, штмл страницу и т.д.


Цитата:

А вы задумывались как подключить к xslt шаблону вывод модуля (а он предположим использует только свои стили)?

Можно понагляднее вопрос поставить?

Цитата:

Можно конечно чтобы все связи шаблонизатор отслеживал, но это еще медленнее получится....

Как вы себе все это представляете?

Ну. Перед преобразованием всё-равно подгружаеться ЧСЛ шаблон, думаю стандартным думом можно в него добавить пару строк. А список требуемых на данной странице блоков уже пусть выдаёт системма

Цитата:

Хм, мне особенно нравиться в ХСЛТ то, что данные можно вывести в любом формате: рсс ленту, принт-френдли страницу, ртф документ, штмл страницу и т.д.

Можно, если на входе у нас чистое xml дерево (собственно он для этого и создавался ). При наличии в нем html и другого содержимого (всего того что в секциях CDATA) вывести в большинство форматов будет невозможно или возможно, но коряво.

Как мне кажется проблема все равно появится, какой бы подход не использовался (блочный или модификации XSLT DOM). Т.е. рано или поздно мы можем столкнуться с ситуацией когда не сможем получить документ в требуемом формате. (загнул... проблема скорее теоритическая; для блочной структуры более актуальна т.к. блок может возвратить что угодно....)

Скажите как много представлений страницы нужно на самом деле? (т.е. что может понадобиться пользователям кроме html и насколько часто?)

Цитата:

Перед преобразованием всё-равно подгружаеться ЧСЛ шаблон, думаю стандартным думом можно в него добавить пару строк. А список требуемых на данной странице блоков уже пусть выдаёт системма

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

Цитата:

Можно понагляднее вопрос поставить?

Пожалуйста: Вы написали cms систему, которая использует xslt шаблонизатор и поставили её пользователю (ради которого все это и делалось), а он хочет написать (купить) модуль (или добавить какой либо функционал) для вашей системы (купить не обязательно у вас). Этот модуль естественно должен уметь встраивать свой вывод и шаблоны в вашу систему. Как он это сделает?

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