CMS & XSLT

Все мы когда-нибудь загнемся. А пока ничего - пьем, едим и нравимся девушкам. Не всем конечно.

А что, если не секрет, день сегодняшний?

Фигасе, я думал этот рынок несколько моложе... :)

Пока слабореализуемо. В gecko не работает disable-output-escaping, у других - другие проблемы. Кроме того, неизвестно, как XML-документы будут индексироваться поисковиками (видимо, никак). Были примеры, когда исходное дерево "подгонялось" под xhtml, но это, ИМХО, извращение.

TecHMeaT, мы пользовались UMI, в целом съедобная система, хотя есть у них достаточно спорные и странные решения, и XSLT пока явно "на вторых ролях" по сравнению с их собственным шаблонизатором.

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

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

- Всякие постоянные вставки можно реализовывать через подгрузку внешних XML или XSL файлов

- Достаточно нагруженные операции типа отображения деревьев форумов и блогов можно грузить на клиента а не на SQL Типа: http://erum.ru/article/18 (см. HTML код дерева обсуждения темы)

Ну и прочая

Ayavryk, есть еще одна проблема - "сборка" XSLT-шаблона. Ну, можно отдавать на клиент вообще весь шаблон, какой есть, но иногда это сильно дофига. import/include - не знаю, будет ли он по HTTP работать, не пробовал. Кроме того, если проводить не одну трансформацию, а шаблонизировать отдельно вывод каждого модуля (плюсы - легкость кэширования, собственно "модульность", независимость частей приложения), преобразование на клиенте тоже все путает.

Операции, которые грузят SQL, боюсь, на клиент не перекинуть (грузят ведь потому что данных много). Формирование дерева по уже готовой выборки - да, можно делать на клиенте. Конкретно с комментариями - подозреваю, эффективней всего будет строить дерево тупо на пыхе, и отдавать XSLT уже готовое дерево, а не "плоский" список. Но да, не так красиво :)

А я уже. На http://erum.ru правая колонка грузится через xsl:import, включеный в клиентское преобразование http://erum.ru/final.xsl Не пробовал подсасывать внешний XML, но сдается что с этим проблем быть не должно. Оптимизация там за уши притянута, но правую колонку роботы не видят.

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

Не знаю. Я в программировании не силен. И обычно тупо делаю через SQL-запросы. Но похоже что - это наиболее ресурсоемкая операция. Так чего бы ее не пихнуть на клиента?

Ну так это в XSLT самое главное - красота :)

Мнения у всех разные, кто-то за, кто-то против. Возникает вопрос - почему XSLT-верстальщики могут найти более высокооплачиваемую работу чем традиционные HTML-верстальщики?

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

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