xslt-шаблонизаторы

Потому что это глобально и надежно(r)(tm)(c)

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

ну потому что нужен какой-то шаблонный движок а этот вроде как стандартный.

а почему бы и нет ?) набросал шаблонов, сгенерил XML и все готово )

а почему стандарт на шаблонный движок, а не просто на формат шалонов положим?

> все повадились его использовать

Кто это повадился? Мне показалось что времена когда толпы идиотов кидались пихать xml & xslt в каждую дырку прошли. А из преимуществ - стандартизация, независимость от языка на котором пишешь. Правда надо очень долго подумать перед тем как использовать.

>Мне показалось что времена когда толпы идиотов кидались пихать xml & xslt в каждую дырку прошли

да вот не прошли(

>независимость от языка на котором пишешь

xslt все равно надо чемто обрабатывать, такой уж и независимости нет

> xslt все равно надо чемто обрабатывать, такой уж и независимости нет

Ну обрабатывать-то все надо, разница в том что если я договорился с верстальщиком что у меня выдается xml вида ... <content> <header>blah</header> </page> ...

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

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

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

Дерьмо этот xslt. Я нынче фанат cduce :)

> Дерьмо этот xslt. Я нынче фанат cduce :)

ты вендузятник, иди ешь их отходы в виде OOXML

Пыхпых я взял для примера, можно заменить на что угодно. Покажите мне шаблон на смарти (есесно без бизнес-логики), который я спокойно буду использовать в perl? а в java? В случае xml & xslt мне на любом языке нужно будет написать один метод - который будет брать xml, xslt и выдавать результат.

Хотя лучше бы вместо xslt, да и вообще xml, было бы что-то более вменяемое, только что бы работало везде.

> ты вендузятник

Почему?

> ешь их отходы в виде OOXML

Спасибо за заботу, мне пока есть чем питаться.

почему верстальщик должен учить xslt? который практически является чуть ли не ЯП.

inb4: нет, я знаю что можно создать xslt-шаблон без логики, и всю логику отдельно, да. но в таком случае к чему вообще xslt, логику можно на чем угодно уже реализовать. я, btw, так же и к смарти отношусь.

//ОП

заказчик слышал умные буквы, хочет. остальные с разбегу выкидывают это удолбище подальше, а вслед гранату — чтобы точно назад не приползло.

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

основые преимущества xslt для нас - хорошее отделение логики оформления и оформления от логики приложения и стандартизация. И эти два преимущества заруливают всё остальное. Быдлосмарти и прочая дотнетщина рядом не валялись.

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

это ж надо так намудрить чтобы XML+XSLT тормозил. IMHO, наоборот, для того же форума или блога -- можно сделать кеширование отдельных постов. Хранить отдельные посты в XML, кешировать top N постов в RSS и HTML для "тупых" клиентов, а умным клиентом скриптом на JS вытягивать только обновившиеся посты. Типа как Jabber работает.

У тебя каша в голове и неверное представление о реальности. Советую это исправить пока не поздно

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

кстати: как ты предлагаешь кэшировать быстро меняющийся контент? ту же ветку форума, например, куда активно пишут? кстати, учти, что есть, скажем, 10 разных шаблонов, и юзеры, которые эти разные шаблоны используют одновременно. итого — бедный кэшер сожрёт как минимум половину ресурсов только на себя, причём без толку. или надо городить такие мегакостыли, что уже и xslt не страшен: без него ужосна будет.

делай давай как я сказал

невыколупывайся

> кстати: как ты предлагаешь кэшировать быстро меняющийся контент? ту же ветку форума, например, куда активно пишут?

В чём проблема, кстати? Написал кто-нибудь, инвалидировали кеш и всё.

бедный яндекс, как они работают то при таких ужосах непонятно -)

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

не знаю, мне исходники читать не давали. тебе давали? поделись.

"тормозная реализация" -- это отдавать каждый раз при обновлении одного поста всю страницу целиком, вместо одного нового поста, как в NNTP. Ну то есть предлагается NNTP поверх AJAX сделать.

Странно, в чятах уже лет десять как всю страницу не перегружают. Лет двадцать как IRC есть, лет 7 как Жаббер эмулирует IRC/почту поверх XML. А блоги/форумы -- до сих пор в каменном веке, статик страницу целиком грузят.

Мы чят на нетскейповском DHTML лет десять назад писали, типа IRC. Когда ещё слов таких, аяксов и жабиров не было.

>кстати: как ты предлагаешь кэшировать быстро меняющийся контент? ту же ветку форума, например, куда активно пишут?

да запросто. Отдельный пост в отдельном XML, обновлять только "индекс" -- включать новый пост. В индексе -- перечень постов-кусочков, из которых он состоит, и AJAX-скрипт, который кеширует "кусочки" и подгружает только новые (+сдвигает позицию "новых").

Со стороны сервера анализировать паттерны запросов, от одной сессии. Однотипные паттерны -- кешировать.

Кешированное грузить например в отдельный XML (то есть, скешированное=индекс+кусочки в одном файле) и "свежим" клиентам выдавать это скешированное (потом уже подгружать разницу).

>10 разных шаблонов, и юзеры, которые эти разные шаблоны используют одновременно.

оформления? XSLT на клиенте.

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

>бедный кэшер сожрёт как минимум половину ресурсов только на себя

я вот не пойму -- почему ntp или rsync или git push/git pull или NNTP не жрут "ресурсов на синхронизацию", а аяяксовый клиент обязательно сожрать должен? можно ведь его и аккуратно написать

>итого, кэш радостно занимается бесконечными инвалидациями

кешировать надо не страницу целиком, а посты-кусочки на клиенте. А отдавать "кусочки" или по одному, или большим пакетом ("страницей целиком"). Например, кука содержит timestamp последнего поста в топике. При этом при перезагрузке по F5 уже загруженные (раньше этого поста) не должны подгружаться (хотя могут быть варианты если пост удалили), а сервер должен выдавать только посты старше этого поста в куке. То, что он для каждого пользователя должен считать набор выдаваемых постов по-своему (и дополнительно нагружать сервер), по настройкам профиля пользователя (хотя тут можно выкрутиться с jQuery) -- можно обойти, загрузив скешированное очередным пакетом (и показав из него только то, что нужно). А сами пакеты для кеширования выбирать, анализируя типичный поток запросов от одного пользователя (время между запросами, например) или объём изменений (если постов <N, вытягивать по одному, иначе вытягивать целый пакет-дельту (или пакет-снапшот))

В любом случае, это должно тормозить не сильнее, чем отдавать всю страницу целиком.

угу. и молиться, чтобы у юзера js был включен. нафиг-нафиг. это ради форума js врубать?

>кешировать надо не страницу целиком, а посты-кусочки на клиенте. А отдавать «кусочки» или по одному, или большим пакетом ("страницей целиком").

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

static pages имеет смысл именно что для редко меняющегося контента. так тут на чём угодно шаблон делай, всё равно кэш раз в пол-года обновляется.

//cpt:poster

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

2cobold: в Яндексе не софсем чистый xml & xslt и гораздо больше других шаблонизаторов. Насколько мне известно xslt используется теперь только в старых проектах, которые уже исторически завязаны на xslt

да уж, тормознее смарти только смарти. Куда уж тут xslt с ним в этом тягаться то..

штука в том, что у смарти тормоза смарти, а у xslt — тормоза xml плюс тормоза xslt. тормоз на тормоз даёт мегатормоз.