Сомневаюсь я однако, хотя задумка какова! Для быдла обычный ЛОР через бравзе, а для Ъ через TKLOR со всяким фичами.

быдлоэлитаризм - фтопку

Да я вот не пойму, почему ни один форум сейчас XSLT не использует. Удобно ведь, как раз для табличных данных. Ну или хотя бы новости через XML+XSLT для начала сделать.

Вообще XML+XSLT на это не влияет. В самом деле, не надо портить мою идею такими заявлениями. Хотя бы скорость загрузки можно увеличить, нагрузку на сервер уменьшить и т.п. Предлагаю все же хотя бы попробовать сделать в виде отдельного интерфейса. А старый оставить по умолчанию для совместимости.

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

>Да я вот не пойму, почему ни один форум сейчас XSLT не использует. Удобно ведь, как раз для табличных данных. Ну или хотя бы новости через XML+XSLT для начала сделать.

а что удобного-то? по моему так геморрой один XML сгенери, потом XSLT нет чтобы просто хеши в Template Toolkit положить

по идее, XML умеет включать другие XMLи. То есть, "положить хеши" в JS движок который сгенерит XML который выкачает/включит соот. хешам XML'и (кешируя по ходу дела)

>Да я вот не пойму, почему ни один форум сейчас XSLT не использует. Удобно ведь, как раз для табличных данных. Ну или хотя бы новости через XML+XSLT для начала сделать.

Потому что по сведениям Gartner 2-3% сетевых серферов все еще пользуются Windows 98 и браузером IE 4.0 с HTML 3.2, не поддерживающим CSS, XSLT и JS 2.0. Вот из-за них все и стоит на уровне 2001года. Как только они перейдут хотя бы на IE 5, или 6, не останется причин отдавать клиентам голый HTML с вшитыми намертво в каждую страницу стилями. Ах да, многие же смотрят сайты с мобилок а их мощности еще пока недостаточно для поддержки CSS и JS

А в Emacs-w3m XSLT разве поддерживается?

Re^2: XML, XSLT, TkLOR

> Да я вот не пойму, почему ни один форум сейчас XSLT не использует.

Потому что писать что-то более сложное, чем приделывание css-ки к таблице на xslt сложновато... А уж править -- так вообще убиться легче.

> Да я вот не пойму, почему ни один форум сейчас XSLT не использует. Удобно ведь, как раз для табличных данных

удобно это когда данные в xml хранятся, а так - xml собери, потом его распарси и наложи xslt. где профит то?

Так отдавать то XML с XSLT. Браузеры будут парсить и накладывать XSLT. А всякие TKLOR будут XML по-своему показывать.

А нужны ли нам такие люди на ЛОРе, которые юзают Win98 и IE?

>Потому что по сведениям Gartner 2-3% сетевых серферов все еще пользуются Windows 98 и браузером IE 4.0 с HTML 3.2, не поддерживающим CSS, XSLT и JS 2.0. Вот из-за них все и стоит на уровне 2001года.

Ничего из-за них не стоит. На них уже положили давно, как и на тех, кто не использует яваскрипт.

>Как только они перейдут хотя бы на IE 5, или 6, не останется причин отдавать клиентам голый HTML с вшитыми намертво в каждую страницу стилями.

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

>Ах да, многие же смотрят сайты с мобилок а их мощности еще пока недостаточно для поддержки CSS и JS

Как раз эта проблема решается отдельной простой версией для мобилок, которая делается через xhtml и css намного проще.

> Будет ли форум когда-нибудь переведен на XML + XSLT?

А есть более конкретные соображения? Сам интересуюсь FXSLT, но вот только не знаю, насколько далеко можно зайти, делая cache-friendly сайт на нём.

Пжалста. Вот обычный plain HTML форум: последняя страница не кешируется, перегружается целиком из-за того, что 1) изменяется количество постов 2) изменяется набор постов (в настройках разных пользователей разный пользователь игнорит разных других, поэтому для двух таких пользователей скешировать не удастся). То есть, кеширование работает только для какого-то "обобщённого профиля", типа анонимусов. Вот простой форум с кешированием: простыня топика на N постов длиной делится на M=(N div n)+1 "страниц" по n постов в каждой. То есть, расчёт на то, что из 100 анонимусов 50 не ходит дальше первой страницы, и соответвенно, ловят скешированный вариант. Для последней страницы кеширование всё равно не работает (хотя есть вариант если обновляют часто, отдавать не из базы, а из статик копии с некоторым интервалом).

Расчёт на XML+XSLT в том, что 1) во-первых, не грузить %CPU на сервере, для формирования страницы, грузить клиента 2) перегружать придётся не всю страницу целиком, а только изменившиеся посты (тут есть засада, если разрешаем редактировать или удалять посты (например, модератор с плюсомётом)).

Клиенту отдаётся AJAX HTML:=XHTML +JS движок. В XHTML "страницы топика" прописано, из каких постов он состоит. JS движок формирует на клиенте XML со ссылками на другие микропосты. То есть, отдельные посты лежат в отдельных XML и подгружаются по ходу дела. Идея в том, что при перезагрузке по F5 JS движок вспомнит, что эти XML подгружены, и второй раз их грузить не будет. То есть, на клиенте вручную, через JS формируется кеш этих отдельных XML постов.

Чтобы не грузить по одному, можно например, кешировать по n последних постов сразу. И кешировать по "алгоритму двойняшек", например (как страницы виртуальной памяти в пейджере FreeBSD): отдавать сначала p последних постов, потом p/2, потом p/4, p/8 и т.п. То есть, кешируются куски длиной кратной p/k.

> В XHTML "страницы топика" прописано, из каких постов он состоит

родилась полуидиотическая идея -- обойтись без БД, голые файлы + git. В ./.git лежит хранилище файлов-блобов, адресуемых по содержимому, хешем от содержимого. Потом от множества хешей отдельных файлов считается общий хеш -- это id "директории". То есть, конкретного состояния дерева ФС. Теперь, у нас файлы -- посты, хеш "id директории" идёт целиком в XHTML страницы топика. У каждого регистранта -- своя ветка, в которую движок при постинге ложит то, что согласуется с его профилем (или наоборот, в ветку ложится, что конкретный регистрант игнорит) .

Сам движок должен переодически делать commit и ставить теги на кешированное состояние (n, p,p/2,p/4,p/8 последних постов). При "постинге" создаётся отдельный новый файл, перерасчитывается "id директории", с интервалом кратным НОД (p,p/2,p/4,p/8,...) перерасчитывается "кешированное", делается commit скешированного.

Получается, СУБД тут нужно только для поиска по строкам. Ну и "распределённые блоги" типа.