Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 206
1. В целом, согласен, что применение XSLT — это шаг вперед.
2. Слова же о невозможности отчуждения проектов, в которых использован Smarty, видятся мне спорными. Здесь как кто напишет. Есть культура программирования в фирме — напишут нормально. Нет культуры программирования — и бизнес-логику с представлением смешают, и кучу врапперов к врапперам врапперов напридумывают :) С другой стороны, XSLT дисциплинирует и способствует снятию большого количества геморроя для директора студии в будущем, когда штат программеров, работавших над каким-то давним сайтом, ротируется, а исправления или дополнения в таком проекте приведут к потерям оплачиваемого рабочего времени на разборки с кодом и бакгфиксы к багфиксам.
3. Наконец-то стали говорить о производительности XSLT и адекватности применяемых решений. Давно ждал, кто же ответит Сергею Рыжикову на его слова ( ага, кто бы говорил :-) ) про "низкую производительность" и "требования к отдельному серверу".
2. Слова же о невозможности отчуждения проектов, в которых использован Smarty, видятся мне спорными. Здесь как кто напишет. Есть культура программирования в фирме — напишут нормально. Нет культуры программирования — и бизнес-логику с представлением смешают, и кучу врапперов к врапперам врапперов напридумывают :) С другой стороны, XSLT дисциплинирует и способствует снятию большого количества геморроя для директора студии в будущем, когда штат программеров, работавших над каким-то давним сайтом, ротируется, а исправления или дополнения в таком проекте приведут к потерям оплачиваемого рабочего времени на разборки с кодом и бакгфиксы к багфиксам.
3. Наконец-то стали говорить о производительности XSLT и адекватности применяемых решений. Давно ждал, кто же ответит Сергею Рыжикову на его слова ( ага, кто бы говорил :-) ) про "низкую производительность" и "требования к отдельному серверу".
Леша, ты бы лично стал разбирать чужой код на Smarty? Особенно, если тот, кто его писал не отвечает на звонки и письма?
Я не говорю, что Smarty плохой, я говорю о его недостатках ;)
Я не говорю, что Smarty плохой, я говорю о его недостатках ;)
Стал бы или нет? Ну это зависит от ситуации. Воможно, был бы вынужден :-)
Проблема с неотвечанием на звонки и письма очень знакома, особенно если с фрилансерами работать. Потому стараемся давать людям некоторые стандарты кодирования, смотрим их код перед тем, как решить, работать ли с ними.
Проблема с неотвечанием на звонки и письма очень знакома, особенно если с фрилансерами работать. Потому стараемся давать людям некоторые стандарты кодирования, смотрим их код перед тем, как решить, работать ли с ними.
так вот, а в случае XSLT ты бы вообще так не парился - искать автора или разбираться в его коде самому.
преемственность кода XSLT от разработчика к разработчику выше на порядок - это и есть отчуждаемость
преемственность кода XSLT от разработчика к разработчику выше на порядок - это и есть отчуждаемость
В общем, да. Как я и сказал, XSLT дисциплинирует :)
а разве на XSLT нельзя "нафигачить" так, что потом сторонний разработчик не разберется?
мне не понравилось редактировать шаблон vBulletin, пусть он даже более структурированный. со Smarty в Shopscript я быстрее разобрался, хотя и там тоже было написано кривыми руками.
а в минус XSLT не идет огромный размер шаблона?
мне не понравилось редактировать шаблон vBulletin, пусть он даже более структурированный. со Smarty в Shopscript я быстрее разобрался, хотя и там тоже было написано кривыми руками.
а в минус XSLT не идет огромный размер шаблона?
везде можно "нафигачить"
у меня был опыт с точностью до наоборот, переход с одного языка на другой всегда влечет за собой подобный эмоциональный дисбаланс
а кто заставляет все пихать в один шаблон?? вы плохо знакомы с XSLT
у меня был опыт с точностью до наоборот, переход с одного языка на другой всегда влечет за собой подобный эмоциональный дисбаланс
а кто заставляет все пихать в один шаблон?? вы плохо знакомы с XSLT
шаблоны можно разбивать. и нужно.
и использовать повторно. например отдельный шаблон для генерации типичных форм. а если сделать правильно все - то многие шаблоны от проекта к проекту вообще редактировать не нужно будет - все представление будет менять при помощи цсс.
но это все требует "вгружения" в технологию, т.к. XSLT имеет принципиально иную идеологию нежели тот же Smarty...
и использовать повторно. например отдельный шаблон для генерации типичных форм. а если сделать правильно все - то многие шаблоны от проекта к проекту вообще редактировать не нужно будет - все представление будет менять при помощи цсс.
но это все требует "вгружения" в технологию, т.к. XSLT имеет принципиально иную идеологию нежели тот же Smarty...
чтобы не писать xslt-файлы огромных размеров можно пользоваться директивами xsl:import & xsl:include. если правильно использовать технологию(xslt), то очень гибко и удобно получается. уже около 3-х лет работаю с ней и всегда какие-нибудь нюансы узнаю.
Это не совсем верно. С XSLT тоже можно "попариться", особенно если он был написан криворуким верстальщиком. Испытано на своем опыте.
всё таки, хоть и не говорите, но подтекстом таки чувствуется "смарти плохой"
то же самое, что говорить - пхп плохой
давайте сразу тогда писать на руби? :-)
то же самое, что говорить - пхп плохой
давайте сразу тогда писать на руби? :-)
хм, а я вот склонна согласиться с Сергеем Котыревым относительно Смарти. Допустим, сайт делает не студия со штатом разработчиков, а фрилансер. Потом нам сайт надо модернизировать, приукрасить, в общем, заняться тюнингом проекта. Далеко не всегда есть возможность обратиться к "отцу" сайта - первому разработчику. А пригласите Вы другого, он скажет: "Э, нет, друг! Тут все нафиг надо переписывать, переделывать и вообще - все не по уму". Имхо, внушительный счет на N-ное количество килобаксов заставить помянуть Смарти не слишком добрым словом. К сожалению, таких историй море, так что вопрос целесообразности использования ХСЛТ актуален. Только где вот программеров XSLT-шных брать - вот в чем вопрос?
Изначально я хотел, чтоб у нас в продукте появилась поддержка Smarty. И вопрос кадров меня больше всего останавливал, когда наши девелоперы стали убеждать меня в преимуществах XSLT против Smarty. Они меня переубедили тогда.
И вопрос специалистов оказался решаемым - все три человека, которые сейчас занимаются XSLT у нас в офисе, все пришли без знания оного. Средний срок обучения - один месяц.
И вопрос специалистов оказался решаемым - все три человека, которые сейчас занимаются XSLT у нас в офисе, все пришли без знания оного. Средний срок обучения - один месяц.
Воспитывать из верстальщиков. Из одаренных и любопытных.
В моей практике встречались такие технологи, которые из верстки ушли в серьезный Ajax или в программинг на Flash. Также может получиться и с XSLT. Был бы спрос - а любопытные и прогрессивные найдутся.
Плюс еще момент, который мне кажется важным... Есть разные уровни подготовки, которые востребованы для разных задач. То есть для какого-то сложного проекта нужен именно XSLT-программист (разработка модулей, шаблонов и т.п. с нуля), а для более простых проектов будет достаточно технолога, который просто использует уже готовые решения.
XSLT-программеры сейчас в дефиците, а технологов можно подготовить.
В моей практике встречались такие технологи, которые из верстки ушли в серьезный Ajax или в программинг на Flash. Также может получиться и с XSLT. Был бы спрос - а любопытные и прогрессивные найдутся.
Плюс еще момент, который мне кажется важным... Есть разные уровни подготовки, которые востребованы для разных задач. То есть для какого-то сложного проекта нужен именно XSLT-программист (разработка модулей, шаблонов и т.п. с нуля), а для более простых проектов будет достаточно технолога, который просто использует уже готовые решения.
XSLT-программеры сейчас в дефиците, а технологов можно подготовить.
на самом деле это суперская идея.
студии могут делать однотипные по функционалу проекты на одних и тех же шаблонах и при этом это будут разные сайты (в разных дизайнах и компоновках).
у нас один партнер однажды собрался сделать около сотни разных сайтов для одного клиента на одной коробке - так он больше всех был рад xslt ))
студии могут делать однотипные по функционалу проекты на одних и тех же шаблонах и при этом это будут разные сайты (в разных дизайнах и компоновках).
у нас один партнер однажды собрался сделать около сотни разных сайтов для одного клиента на одной коробке - так он больше всех был рад xslt ))
В свое время были в дефиците верстальщики на CSS. Но когда требования верстка на div является обязательным - люди начинают учится данной технологии - пускай даже и принудительно.
Лидеры рынка должны задавать правильный вектор развития технологий, что бы молодые специалисты понимали куда стремится - а не делать на том что проще изучить.
Лидеры рынка должны задавать правильный вектор развития технологий, что бы молодые специалисты понимали куда стремится - а не делать на том что проще изучить.
С другой стороны, что мешает сказать то же самое XSLT-шнику? :))
появление специалистов XSLT - вопрос времени. воспитывайте культуру. в том числе, уважение к заказчику и его деньгам. я отчасти им являюсь, и заинтересована в расширяемых и динамичных проектах.
Брать нас и учить :)
На самом деле я этой технологией заинтересовался года 3 назад, когда пытался написать свою CMS :)) точнее пришел к выводу что логика должна давать данные в XML и шаблон должен быть на XML и после нескольких попыток изобрести велосипед "наткнулся" на XSLT, я был очарован, но...
Но некоммерческих проектов не было, на коммерческих, сами понимаете, не мог сказать заказчику "можно, за 3 дня сделать на Smarty, но подождите 2 недели, я буду XSLT осваивать, еще, желательно, мне это время оплатить" :( попытки делал освоить XSLT в процессе, но заканчивались тем, что в авральном порядке на кофе и адреналине переводил все отображение на чистый php/smarty
Информации практически нет о XSLT, точнее о его практическом использовании, изобретать велосипед каждый раз нет возможности, исходников серьезных проектов никто не даст, конечно. По стандарту да справочникам только примитивные преобразования изучать. Популярные открытые CMS/CMF XSLT если и поддерживают, то не нативно, шаблонов рабочих вообще не найдешь под них, рускомьюнити, где помогли бы сделать шаг от хрестоматийных примеров к реальным системам тоже не обнаружил... Вакансий, где требуется начальные знания XSLT тоже минимум, по крайней мере в Питере - либо вообще не упоминают, либо хотят уже профессиональное знание и практические навыки эффективной работы...
так что так и остается использование XSLT недоступной мечтой, вроде и знаю что-то, и вывод данных страницы на XML только рад делать, и даже делаю, но потом их парсю в массивы и вывожу чрез что придется
На самом деле я этой технологией заинтересовался года 3 назад, когда пытался написать свою CMS :)) точнее пришел к выводу что логика должна давать данные в XML и шаблон должен быть на XML и после нескольких попыток изобрести велосипед "наткнулся" на XSLT, я был очарован, но...
Но некоммерческих проектов не было, на коммерческих, сами понимаете, не мог сказать заказчику "можно, за 3 дня сделать на Smarty, но подождите 2 недели, я буду XSLT осваивать, еще, желательно, мне это время оплатить" :( попытки делал освоить XSLT в процессе, но заканчивались тем, что в авральном порядке на кофе и адреналине переводил все отображение на чистый php/smarty
Информации практически нет о XSLT, точнее о его практическом использовании, изобретать велосипед каждый раз нет возможности, исходников серьезных проектов никто не даст, конечно. По стандарту да справочникам только примитивные преобразования изучать. Популярные открытые CMS/CMF XSLT если и поддерживают, то не нативно, шаблонов рабочих вообще не найдешь под них, рускомьюнити, где помогли бы сделать шаг от хрестоматийных примеров к реальным системам тоже не обнаружил... Вакансий, где требуется начальные знания XSLT тоже минимум, по крайней мере в Питере - либо вообще не упоминают, либо хотят уже профессиональное знание и практические навыки эффективной работы...
так что так и остается использование XSLT недоступной мечтой, вроде и знаю что-то, и вывод данных страницы на XML только рад делать, и даже делаю, но потом их парсю в массивы и вывожу чрез что придется
На мой взгляд забыли упомянуть, что XSLT давольно расширяемый язык, и тем кого не устраивают стандартные возможности - могут подключить дополнительные расширения для языка, написанные сторонними разработчиками (яркий пример расширения проекта http://exslt.org/).
Когда речь заходит о выборе той или иной технологии нужно абсолютно точно понимать что в любом случае тебе придется платить. Вопрос лишь в том - сколько? и за что? Любой инструмент призван решать конкретную задачу - отвертка закручивает винты, а молоток забивает гвозди.
У XSLT есть только одно слабое место, за которое так любят цеплятся его противники - производительность; и речь, зачастую, идет даже не о времени самой трансформации, а о лишнем шаге преобразования данных в xml, поскольку XSLT работает только с xml. Но я не слышал ни одного аргумента против XSLT с архитектурной точки зрения, потому что их нет. И я могу абсолютно точно сказать, не вдаваясь в детали, что в этом плане XSLT делает любой шаблонизатор, и тот, кто его использует, прекрасно знает за что он платит!
CMS, на мой взгляд, является универсальным средством создания сайтов, а значит должна позволять решать самые разные задачи, и для каждой конкретной задачи должна предоставлять необходимый инструмент, иными словами не только гвозди забивать, но и винты закручивать...
P.S. А еще есть чисто субъективные моменты, XSLT - красив!
У XSLT есть только одно слабое место, за которое так любят цеплятся его противники - производительность; и речь, зачастую, идет даже не о времени самой трансформации, а о лишнем шаге преобразования данных в xml, поскольку XSLT работает только с xml. Но я не слышал ни одного аргумента против XSLT с архитектурной точки зрения, потому что их нет. И я могу абсолютно точно сказать, не вдаваясь в детали, что в этом плане XSLT делает любой шаблонизатор, и тот, кто его использует, прекрасно знает за что он платит!
CMS, на мой взгляд, является универсальным средством создания сайтов, а значит должна позволять решать самые разные задачи, и для каждой конкретной задачи должна предоставлять необходимый инструмент, иными словами не только гвозди забивать, но и винты закручивать...
P.S. А еще есть чисто субъективные моменты, XSLT - красив!
Разговоры о низкой производительности XSLT вызваны у разных людей разными причинами:
1. Кто-то неправильно его применил (есть чудаки, хранящие в XML каталоги товаров) и закономерно получил тормоза.
2. Кто-то просто не умеет с ним работать (не смог реализовать в своей CMS), ему проще сидеть на смарти, а XSLT — дискредитировать.
3. Кто-то наслушался первых двух, а сам знаниями достаточными не обладает, но охотно ретранслирует чушь :)
1. Кто-то неправильно его применил (есть чудаки, хранящие в XML каталоги товаров) и закономерно получил тормоза.
2. Кто-то просто не умеет с ним работать (не смог реализовать в своей CMS), ему проще сидеть на смарти, а XSLT — дискредитировать.
3. Кто-то наслушался первых двух, а сам знаниями достаточными не обладает, но охотно ретранслирует чушь :)
1. Уж мне-то не надо говорить о неправильности его применения, я к данному внедрению имею вроде как не самое последнее отношение ) еще раз подчеркну речь даже не о самой трансформации, а о лишнем этапе трансляции данных в xml
2. см. п.1
3. см. п.1
2. см. п.1
3. см. п.1
технологии осваиваются после понимания их преимуществ. понимание приходит с опытом. опыт со временем.
я сам в бизнесе веб-разработки с 2000 года, но еще полгода назад я бы не сел писать такую статью, т.к. сомневался.
сейчас увидел, многое понял, посчитал, поумнел, написал.
через месяц, полгода или год и остальные поймут потихоньку и начнут осваивать xslt. может даже Битрикс одумается.
я сам в бизнесе веб-разработки с 2000 года, но еще полгода назад я бы не сел писать такую статью, т.к. сомневался.
сейчас увидел, многое понял, посчитал, поумнел, написал.
через месяц, полгода или год и остальные поймут потихоньку и начнут осваивать xslt. может даже Битрикс одумается.
как это ни странно звучит, но понимание недостатков приходит сразу вслед за пониманием преимуществ, а не наоборот; когда период опьянения от новой технологии проходит и взгляд становится более трезвым. В силу вступает холодный прагматизм и расчет. Тебе все еще нравится XSLT, но ты понимаешь что вокруг есть и другие)
Ну это не про Вас мой комментарий был :)
Почитал статью Рыжикова и офигел. Да и у вас то же самое - зачем перегонять данные в _текстовый_ xml файл (не совсем понял что вы имели в виду, но у Рыжикова именно так)? Там же написано - для того, чтобы прогнать по нему xml-парсер. Ужос. Кто мешал складывать данные сразу в дом-дерево? Ай да Рыжиков, ай да "шпециалист" :(
У меня тоже был легкий шок, хоть я не программист. :)
Складывать данные в DOM? Ну это когда данных немного и памяти достаточно. ;)
Для разбора составного датасета в XML лучше применять какой-нибудь SAX-парсер, а не DOM.
Для разбора составного датасета в XML лучше применять какой-нибудь SAX-парсер, а не DOM.
бр-бр-бр… осмелюсь спросить, что такое dom-дерево, если не объектная структура и как ее передавать между независимыми компонентами? вот создал я на своем php dom-дерево и надо мне его послать другой программе, которая на это дерево натравит xslt-шаблон… мои действия могут быть следующими:
* упаковать в xml
* упаковать в иную сериализованную строку
* упаковать в какой-нибудь бинарный формат, желательно понятный как php, так и libxslt
что делать?)
* упаковать в xml
* упаковать в иную сериализованную строку
* упаковать в какой-нибудь бинарный формат, желательно понятный как php, так и libxslt
что делать?)
Я не очень понимаю как это — создать на пхп дом-дерево и послать другой программе. Какой другой программе? Пхп — это язык для написания веб-фронтендов, разве нет? Отдельностоящие компоненты, написаные на пхп и передающие данные другим компонентам? Что могло сподвигнуть на выбор пхп в качестве основного языка для реализации такой архитектуры?
Кстати, из ваших вариантов мне больше нравится второй.
Если всё это крутится внутри одного аппсервера, разумеется (ну, или группы тесно взаимодействующих серверов). Если надо общаться с миром «извне», то, ясное дело, xml вполне.
Кстати, из ваших вариантов мне больше нравится второй.
Если всё это крутится внутри одного аппсервера, разумеется (ну, или группы тесно взаимодействующих серверов). Если надо общаться с миром «извне», то, ясное дело, xml вполне.
Для XSLT-преобразований я хочу использовать nginx + xslt, у которого уже подгружены все необходимые шаблоны. Собственно, в каком виде иначе как в XML мне передавать ему данные от php? Промелькнула мысль «зачем в php упаковывать данные в xml, чтобы xslt-шаблонизатор его парсил, когда можно передать dom-дерево». Вот мне и интересно, как передать это самое dom-дерево)
Кстати, о производительности — есть у nginx модуль для работы с xslt. Шаблоны парсятся при чтении конфигурации и затем натравливаются на выход с бакэндов или xml-файлов. Кто-нибудь пользовался?
Smarty тоже достаточно расширяем. XSLT - хорошее решение, но не всегда его необходимо.
Будте мудрее и думайте перед тем кк сделать выбор в сторону одного или другуго.
P.S. Для нас оказался ближе Смарти.
Будте мудрее и думайте перед тем кк сделать выбор в сторону одного или другуго.
P.S. Для нас оказался ближе Смарти.
Не крест, конечно же. Но для новичков, а также для управленческого состава статья Сергея Рыжикова вполне может служить причиной пагубного отказа от XSLT. Как же ж! Тормозит, дескать. Дескать, требует отдельного сервера.
Хотя отдельного сервера требует, как раз, совсем другой продукт ;-)
Хотя отдельного сервера требует, как раз, совсем другой продукт ;-)
По поводу статьи Б. Лично мной примерно так и воспринимается. В ней я прочитал, что в XSLT неэффективно делать вещи, которые в нем на самом-то деле и эффективны.
Насчет выбора Smarty в качестве основного фигуранта данной статьи. Нужно же было кого-то выбрать. Тем более, что основная версия Б. все-таки на php.
А в .NET'е XSLT - это уже стандарт де-факто, который компанией M$ продвигается. У моих .net'ских коллег факт использования чего-то кроме XSLT вообще вызывает сильное удивление.
Насчет выбора Smarty в качестве основного фигуранта данной статьи. Нужно же было кого-то выбрать. Тем более, что основная версия Б. все-таки на php.
А в .NET'е XSLT - это уже стандарт де-факто, который компанией M$ продвигается. У моих .net'ских коллег факт использования чего-то кроме XSLT вообще вызывает сильное удивление.
не понравилась статья, сплошное повторение избитых фактов о разделении логики, о реальной производительности ни слова
В том то и дело, что производительность XSLT намного выше (это факт), но только при правильной логике.
Поэтому и "повторение избитых фактов о разделении логики", что бы люди понимали что дело не в XLST - а в не правильном его использовании.
Поэтому и "повторение избитых фактов о разделении логики", что бы люди понимали что дело не в XLST - а в не правильном его использовании.
приведите примеры, я тут ниодного примера не видел, только голословные утверждения
Примеры чего вы хотите тут увидеть сравнительные тесты обработки вывода как шаблонизатором так и XSLT? Это приведет к тому, что будут рассматривать уже шаблонизаторы и говорить, что у вас там шаболнизатор плохой а вот у нас он делает это быстрей. И в итоге отдалимся от тему статьи.
Как уже упоминалось что на западе XML/XSLT становиться уже де-фактом разработки CMS - это по вашему голословные утверждения?
То что все больше и больше крупных российских сервисов созданы на этой технологии - тоже голословные утверждения?
Для меня как для разработчика голословным утверждением является, то что XSLT тормозит и никуда не годнен.
Как уже упоминалось что на западе XML/XSLT становиться уже де-фактом разработки CMS - это по вашему голословные утверждения?
То что все больше и больше крупных российских сервисов созданы на этой технологии - тоже голословные утверждения?
Для меня как для разработчика голословным утверждением является, то что XSLT тормозит и никуда не годнен.
отдалимся? нет, мы просто увидим что статья - мягко говоря не показывает всю полноту картины)))
нет, в это я готов легко и непринужденно поверить.
интересно, а на чем работает хабр?))
я такого не утверждал, у меня есть примеры сильно тормозящего xslt, но я не могу их предъявить - это закрытый код и мне он не принадлежит поэтому я хотел бы что бы кто-нибудь продемонстрировал сравнительный анализ по данному вопросу.
з.ы. iqeek (чуть ниже) - очень все правильно написал, вопрос ведь даже не в том тормозит/не тормозит - любые процессы кушают и проц и память, вопрос в том сколько это стоит в рублях и что дороже/дешевле
нет, в это я готов легко и непринужденно поверить.
интересно, а на чем работает хабр?))
я такого не утверждал, у меня есть примеры сильно тормозящего xslt, но я не могу их предъявить - это закрытый код и мне он не принадлежит поэтому я хотел бы что бы кто-нибудь продемонстрировал сравнительный анализ по данному вопросу.
з.ы. iqeek (чуть ниже) - очень все правильно написал, вопрос ведь даже не в том тормозит/не тормозит - любые процессы кушают и проц и память, вопрос в том сколько это стоит в рублях и что дороже/дешевле
Спорно :)
я могу не использовать рекурсию, а использовть xsl:for-each да еще и вложить и вдруг друга, а также паруз раз сделать match на корень документа для вытягивания каки-либо праметров - И У МЕНЯ ВСЕ ТОЖЕ БУДЕТ ТОРМОЗИТЬ.
Но это показатель того, что круворукий разработчик, а не XSLT плохой. :)
Ничего личного :)
я могу не использовать рекурсию, а использовть xsl:for-each да еще и вложить и вдруг друга, а также паруз раз сделать match на корень документа для вытягивания каки-либо праметров - И У МЕНЯ ВСЕ ТОЖЕ БУДЕТ ТОРМОЗИТЬ.
Но это показатель того, что круворукий разработчик, а не XSLT плохой. :)
Ничего личного :)
Тоже самое и о Смарти. Почему-то когда говорят о смарти - обвиняют его а не криворукого программера. А когда говорят об XSLT то оно сразу не виновато в тормозах. Кривые программеры есть везде и технология тут не причем. Однако в статье Смарти в недостатки приписывались только кривые программеры. Я вот все думаю - что ж там такое в шаблоне должно быть чтобы надо было вызванивать программиста, а трагедией было бы что он не отвечает?
выше чего?) и где засвидетельствован данный факт?
мне тут вспомнился один момент на ClientSide 2007, когда одного из докладчиков прямо в лоб спросили о производительности XSLT, докладчик как-то сразу замялся и не знал что сказать, тогда Надежда Строганкова взяла микрофон в руки и сказала фразу, которую я очень долго ждал: да, XSLT на порядок дороже по производительности чем перловские шаблонизаторы, но вы знаете за что вы платите. Вот и все, нужно просто понять за что вы платите...
Есть некоторые товарищи)) которые покупают Mac, несмотря на то что он стоит неоправданно дорого по сравнения с другими компами, и особенно в нашей стране. Но они просто знают за что они платят, и готовы платить. В XSLT тоже есть нечто за что можно и нужно платить.
Далеко не на всех проектах необходимо вести борьбу за каждую милисекунду, но даже на тех проектах где это жизненно необходимо, люди готовы расплачиваться производительностью, в обмен на что? Когда вы поймете за что вы готовы платить, вы будете платить!
мне тут вспомнился один момент на ClientSide 2007, когда одного из докладчиков прямо в лоб спросили о производительности XSLT, докладчик как-то сразу замялся и не знал что сказать, тогда Надежда Строганкова взяла микрофон в руки и сказала фразу, которую я очень долго ждал: да, XSLT на порядок дороже по производительности чем перловские шаблонизаторы, но вы знаете за что вы платите. Вот и все, нужно просто понять за что вы платите...
Есть некоторые товарищи)) которые покупают Mac, несмотря на то что он стоит неоправданно дорого по сравнения с другими компами, и особенно в нашей стране. Но они просто знают за что они платят, и готовы платить. В XSLT тоже есть нечто за что можно и нужно платить.
Далеко не на всех проектах необходимо вести борьбу за каждую милисекунду, но даже на тех проектах где это жизненно необходимо, люди готовы расплачиваться производительностью, в обмен на что? Когда вы поймете за что вы готовы платить, вы будете платить!
>>выше чего?) и где засвидетельствован данный факт?
Как прасер XML - XSLT самый производительный :)
Как прасер XML - XSLT самый производительный :)
как не странно но на том же ClientSide 2007, в секции шаблонизаторов был только XSLT
а вообще нужно понимать за что вы платите и что вы эконовите, в случае XSL вы платите больше за серверные ресурсы, но при этом сокращаете затраты человеческого времени на разработку и поддержку
а вообще нужно понимать за что вы платите и что вы эконовите, в случае XSL вы платите больше за серверные ресурсы, но при этом сокращаете затраты человеческого времени на разработку и поддержку
А почему не рассматривается вопрос о том, что XML/XSLT шаблоны в коде весит намного больше, чем какой-то специализированный шаблонный движок, что приводит в конечном счете к увеличению количества и размера файлов проекта, увеличению времени на разработку и тестирование.
> В свое время были в дефиците верстальщики на CSS.
верстка по стандартам с использованием CSS приводит как раз к уменьшению кода и затрат на его сопровождения
> В свое время были в дефиците верстальщики на CSS.
верстка по стандартам с использованием CSS приводит как раз к уменьшению кода и затрат на его сопровождения
1) XSL шаблон не настолько больше весит, а при правильном проектировании может весить и меньше
2) XSL просто читается что повышает скорость его чтения
3) XSL хорошо структурирован, что позволяет просто навигироваться даже в большом шаблоне
4) увеличение размера шаблона лишь косвенно может увеличить время на разработку
5) XSL есть практически везде, что позволяет использовать XSL разработчиков практически во всех задачах требующих отображения данных, начиная от построения отчетов заканчивая сложными JavaScript приложениями что сокращает расходы
6) XSL можно накладывать на клиентской стороне, что сильно экономит серверные ресурсы и снижает расходы на эксплуатацию проекта
2) XSL просто читается что повышает скорость его чтения
3) XSL хорошо структурирован, что позволяет просто навигироваться даже в большом шаблоне
4) увеличение размера шаблона лишь косвенно может увеличить время на разработку
5) XSL есть практически везде, что позволяет использовать XSL разработчиков практически во всех задачах требующих отображения данных, начиная от построения отчетов заканчивая сложными JavaScript приложениями что сокращает расходы
6) XSL можно накладывать на клиентской стороне, что сильно экономит серверные ресурсы и снижает расходы на эксплуатацию проекта
1 - Пример в студию
2 - А что , тимплейтные движки делаю что-то другое?
3 - ГРАМОТНЫЙ шаблон В ЛЮБОМ движке читается легко и прост для навигации
4 - по-моему, как раз таки прямо увеличивает.
5 - HTML тоже есть везде, а еще везде есть текстовые файлы :) . Не аргумент. Сложные JS приложения используют на XSLT а xml, и то не особенно удачно (повреждение при передаче = ошибка).
6 - Увеличение трафика и убийство слабой техники пользователями.
2 - А что , тимплейтные движки делаю что-то другое?
3 - ГРАМОТНЫЙ шаблон В ЛЮБОМ движке читается легко и прост для навигации
4 - по-моему, как раз таки прямо увеличивает.
5 - HTML тоже есть везде, а еще везде есть текстовые файлы :) . Не аргумент. Сложные JS приложения используют на XSLT а xml, и то не особенно удачно (повреждение при передаче = ошибка).
6 - Увеличение трафика и убийство слабой техники пользователями.
1) давайте пример данных, я вам приведу пример реализации
2) я имел в виду разработчиков
3) вот именно что грамотный, только вто зачастую качество девелопмента страдает...
4) обоснуйте
5) и что для каждого языка теперь учить новый шаблонизатор?
6) в ряде случаев это не увеличение, а снижения трафика + что вы понимаете под словом слабой?
2) я имел в виду разработчиков
3) вот именно что грамотный, только вто зачастую качество девелопмента страдает...
4) обоснуйте
5) и что для каждого языка теперь учить новый шаблонизатор?
6) в ряде случаев это не увеличение, а снижения трафика + что вы понимаете под словом слабой?
1- Пример предоставляет доказующая сторона. Иначе - голословные утверждения ;)
2- Возможно, дело привычки
4- Увеличение размера шаблонов -> увеличение времни проектирования, отладки и тестирования -> увеличение стоимости работы
5- В очень редких случаях. Сложное форматирование, большие объемы данных - это верный путь к увеличению. Слабые машинки : 512 Мб ОЗУ, процессор 900Мz
Ладно, есть предложение завершить холивар. Мне не переубедить Вас, Вас - мне. Всякой технологии свое место и время.
2- Возможно, дело привычки
4- Увеличение размера шаблонов -> увеличение времни проектирования, отладки и тестирования -> увеличение стоимости работы
5- В очень редких случаях. Сложное форматирование, большие объемы данных - это верный путь к увеличению. Слабые машинки : 512 Мб ОЗУ, процессор 900Мz
Ладно, есть предложение завершить холивар. Мне не переубедить Вас, Вас - мне. Всякой технологии свое место и время.
размер файла никак не связан со временем разработки и тестированием.
если Вы вместо длинных имен переменых будете использовать короткие, Вы уменьшите размер файла, но увиличите время на разработку и тестирование.
По этому нельзя так категорично утверждать.
XSLT, в силу синтаксиса XML, но в этом его и плюс, шаблон можно провалидировать.
если Вы вместо длинных имен переменых будете использовать короткие, Вы уменьшите размер файла, но увиличите время на разработку и тестирование.
По этому нельзя так категорично утверждать.
XSLT, в силу синтаксиса XML, но в этом его и плюс, шаблон можно провалидировать.
про производительность - нигде я не имел ввиду, что скорость рендеринга/парсинга/передачи XSLT меньше, чем какого-то движка (вопрос не об этом), я говорил только о скорости написания-отладки-изменения таких шаблонов программистом. Есть у меня проект написанный с использованием XSLT, так вот добавление обычно занимает по времени раза в 2 - 4 больше, чем для обычного движка, где можно вставить <%= item.rating %>, при этом откуда идет item.rating и я прекрасно знаю и следующий девлопер будет знать .... а вот реальный код оттуда (сходу его не разобрать)
<xsl:template name="rate_big">
<xsl:param name="already_rated"/>
<xsl:choose>
<xsl:when test="already_rated = '0'">
<xsl:choose><xsl:when test="($iteration < 6)">
<div id="rate_{$iteration}" class="rating" onclick="xajax_r({$iteration},{id});return false;"><span class="hidden">*</span></div>
<xsl:call-template name="rate_big">
<xsl:with-param name="iteration" select="$iteration + 1"/>
<xsl:with-param name="already_rated" select="$already_rated"/>
</xsl:call-template>
</xsl:when></xsl:choose>
</xsl:when>
<xsl:otherwise>
<xsl:choose><xsl:when test="($iteration < 6)">
<div id="rate_{$iteration}" class="rating"><span class="hidden">*</span></div>
<xsl:call-template name="rate_big">
<xsl:with-param name="iteration" select="$iteration + 1"/>
<xsl:with-param name="already_rated" select="$already_rated"/>
</xsl:call-template>
</xsl:when></xsl:choose>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
форматирование фигачится :( ... на мой взгляд код сложный, потому что он не позволяет встраивать код на php/ruby/perl/asp.net
<xsl:template name="rate_big">
<xsl:param name="already_rated"/>
<xsl:choose>
<xsl:when test="already_rated = '0'">
<xsl:choose><xsl:when test="($iteration < 6)">
<div id="rate_{$iteration}" class="rating" onclick="xajax_r({$iteration},{id});return false;"><span class="hidden">*</span></div>
<xsl:call-template name="rate_big">
<xsl:with-param name="iteration" select="$iteration + 1"/>
<xsl:with-param name="already_rated" select="$already_rated"/>
</xsl:call-template>
</xsl:when></xsl:choose>
</xsl:when>
<xsl:otherwise>
<xsl:choose><xsl:when test="($iteration < 6)">
<div id="rate_{$iteration}" class="rating"><span class="hidden">*</span></div>
<xsl:call-template name="rate_big">
<xsl:with-param name="iteration" select="$iteration + 1"/>
<xsl:with-param name="already_rated" select="$already_rated"/>
</xsl:call-template>
</xsl:when></xsl:choose>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
форматирование фигачится :( ... на мой взгляд код сложный, потому что он не позволяет встраивать код на php/ruby/perl/asp.net
а сколько времени займент изменение шаблонов когда проет перейдет с ASP.net на php?
судя по вашему примеру (изобилию call-template/with-param), вы не совсем поняли как писать на XSLT
судя по вашему примеру (изобилию call-template/with-param), вы не совсем поняли как писать на XSLT
а сколько времени займет изменение шаблонов когда проект перейдет с ASP.net на php?
судя по вашему примеру (изобилию call-template/with-param), вы не совсем поняли как писать на XSLT
судя по вашему примеру (изобилию call-template/with-param), вы не совсем поняли как писать на XSLT
> судя по вашему примеру (изобилию all-template/with-param), > вы не совсем поняли как писать на XSLT
можно альтерантивный вариант
> а сколько времени займет изменение шаблонов когда проект > перейдет с ASP.net на php?
пока для меня стоит вопрос так - сайт с большим количеством XSLT понимать сложно и дорабатывать тоже сложно (много времени уходит), при этом простые шаблоны понимаются легко, а сложные шаблоны не публикуются
можно альтерантивный вариант
> а сколько времени займет изменение шаблонов когда проект > перейдет с ASP.net на php?
пока для меня стоит вопрос так - сайт с большим количеством XSLT понимать сложно и дорабатывать тоже сложно (много времени уходит), при этом простые шаблоны понимаются легко, а сложные шаблоны не публикуются
я написал в начале статьи, что ее цель не научить вас на конкретных примерах, а скорее заинтересовать вас самих научиться.
вот пара полезных ссылок для начала:
wikipedia
типа учебник с примерами как все просто делается и сортируется
вот пара полезных ссылок для начала:
wikipedia
типа учебник с примерами как все просто делается и сортируется
если реально хотите заинтересовать - запишите скринкаст и выложите сюда
// желательно чтобы буквы были видны
// желательно чтобы буквы были видны
в том то и дело что у смарти есть привязка к PHP, и если у вас в команде есть верстальщик который знает смарти то что бы он сделал шаблон к примеру для сервера на JAVA или C++ или чего угодно ему нужно учить новый шаблонизатор
а XSL верстальщик может сделать шаблон к любому бекенду, даже не особо задумываясь какие технологии там используются, есть лишь небольшие различия в различных диалектах XSLT процессоров
а XSL верстальщик может сделать шаблон к любому бекенду, даже не особо задумываясь какие технологии там используются, есть лишь небольшие различия в различных диалектах XSLT процессоров
Любая универсальность есть жертва функциональности и скорости.
время хорошего разработчика зачастую стоит дороже железа, так что на с экономненные деньги можно купить более мощное железо.
так что унификация не всегда приводит к потерям в скорости.
так что унификация не всегда приводит к потерям в скорости.
Глупо решать проблему быстродействия новым железом. На примере myspace можно понять что это не решение.
1) XSL не на столько медленнее
2) фронтенды которые занимаются шаблонизацией просто и эффективно кластеризуются
2) фронтенды которые занимаются шаблонизацией просто и эффективно кластеризуются
Пример крупного проекта с большой нагрузкой пожалуйста на базе XSL.
Не думаю, что в MySpace и т.п. проектах до такого не додумались. Или Вы гений или тут есть свои подводные камни.
Не думаю, что в MySpace и т.п. проектах до такого не додумались. Или Вы гений или тут есть свои подводные камни.
практически все:
*.yandex.ru
*.ya.ru
ЗЫ
конкретные проекты лень перечислять
*.yandex.ru
*.ya.ru
ЗЫ
конкретные проекты лень перечислять
Не показатель. Там не на 100% все на XSLT, используются гибридные решения (информация 1.5 летний давности, возможно уже и поменялось-что-то)
http://phpclub.ru/detail/article/2002-05…
"проект соответствующего масштаба (мелкий можно и в виде HTML смешанного с PHP, для крупного XSL тоже не очень подходит)"
http://phpclub.ru/detail/article/2002-05…
"проект соответствующего масштаба (мелкий можно и в виде HTML смешанного с PHP, для крупного XSL тоже не очень подходит)"
ок приведу конкретно:
ya.ru
market.yandex.ru
fotki.yandex.ru
три крупных проекта, и все используют во фрондендах XSL
ya.ru
market.yandex.ru
fotki.yandex.ru
три крупных проекта, и все используют во фрондендах XSL
А можно что-то не от Яндекса?
P.S. дайте ссылка на материалы где написано "Яндекс - это 100% XSLT"
P.S. дайте ссылка на материалы где написано "Яндекс - это 100% XSLT"
не яндекс: soft.oszone.net
яндекс это не 100% XSL (есть вещи где нету XSL, к примеру на морде www.yandex.ru)
яндекс это не 100% XSL (есть вещи где нету XSL, к примеру на морде www.yandex.ru)
10К в день.. не особо нагруженый проект.
Хм, в поиске явно прописаны сыслки - PHP.
Дезинформация какая-то ;)
Хм, в поиске явно прописаны сыслки - PHP.
Дезинформация какая-то ;)
Ну. там шаблончик то очень примитивный, как я вижу из кода странички.
1) в чем заключается его примитивность?
2) почему шаблон не должен быть примитивным? это веть на оборот хорошо!
2) почему шаблон не должен быть примитивным? это веть на оборот хорошо!
Повторяю - "пример крупного проекта с большой нагрузкой пожалуйста на базе XSL."
Вам выдержку дать определение понятия "крупный проект" или "большие нагрузки"?
П.С. Думаю, надо заканчивать холивар. Спасибо за диалог. Удачи Вам в Ваших проектах.
Вам выдержку дать определение понятия "крупный проект" или "большие нагрузки"?
П.С. Думаю, надо заканчивать холивар. Спасибо за диалог. Удачи Вам в Ваших проектах.
Память вещь такая :)
<xsl:stylesheet version="1.0">
<xsl:variable name="имя_переменой" select="какое-то XML дерево" />
<xsl:template match="/">
<xsl:apply-templates select="$имя_переменой" /> <- и делай там что хочешь
</xsl:template>
<xsl:template match="что-то">
<xsl:apply-templates select="$имя_переменой" /> <- и опять же делай там что хочешь
</xsl:template>
</xsl:stylesheet>
<xsl:stylesheet version="1.0">
<xsl:variable name="имя_переменой" select="какое-то XML дерево" />
<xsl:template match="/">
<xsl:apply-templates select="$имя_переменой" /> <- и делай там что хочешь
</xsl:template>
<xsl:template match="что-то">
<xsl:apply-templates select="$имя_переменой" /> <- и опять же делай там что хочешь
</xsl:template>
</xsl:stylesheet>
"Отладка шаблона на XSLT, если в нем допущена ошибка, может потребовать от разработчика существенных усилий по ее нахождению и устранению. При этом даже любой незакрытый тег ведет к неработоспособности всего шаблона. Поэтому XSLT требует от разработчика особой тщательности, аккуратности и внимательности к деталям."
- а как же дебаггеры XSLT, которые есть и в Visual Studio, и для Eclipse?
- а как же дебаггеры XSLT, которые есть и в Visual Studio, и для Eclipse?
именно так!
при использовании таких инструментов, как Eclipse проблем возникать не должно, и обычно не возникает.
но есть любители все редактировать через far+colorer. у них иногда возникают проблемы при командной работе.
при использовании таких инструментов, как Eclipse проблем возникать не должно, и обычно не возникает.
но есть любители все редактировать через far+colorer. у них иногда возникают проблемы при командной работе.
Ясно, спасибо :)
должен заметить что debug, если имеется ввиду именно debug, а не банальная проверка синтаксиса, в XSLT пока еще на порядок хуже и затруднительнее, чем в других языках...
лично я ушел от Eclipse к простому и легкому TextWrangler/XSLPalette, в котором даже проверки синтакcиса нет, я не люблю избыточные среды, если в них нет необходимости, и в большинстве случаев никакой xslt-debugger, не убережет вас от ошибок лучше чем собственная голова, как говорится - на debugger надейся, а сам не плошай)
лично я ушел от Eclipse к простому и легкому TextWrangler/XSLPalette, в котором даже проверки синтакcиса нет, я не люблю избыточные среды, если в них нет необходимости, и в большинстве случаев никакой xslt-debugger, не убережет вас от ошибок лучше чем собственная голова, как говорится - на debugger надейся, а сам не плошай)
По моему мнению Smarty по сравнению с XSLT банальная отрыжка разработчика…
Имею опыт работы с обеими системами и от XSLT как и от всей технологии XML испытываю нескончаемое удовольствие, снимает множество головных болей.
Имею опыт работы с обеими системами и от XSLT как и от всей технологии XML испытываю нескончаемое удовольствие, снимает множество головных болей.
Приходилось учавствовать в разработке довольно известных CMS, одна работала с XSL, другая с обычными шаблонами. Как одна фирма, так и другая занимаются, помимо разработки CMS, еще и разработкой сайтов на своих системах.
Так вот подход, применяемый в фирме, где система с XSL такой, что имеется законченная коробочная версия продукта, и на базе неё уже делается сайт. Все фичти реализуются "легальными способами", т.е. код системы (ядро, модули) не меняется, меняются только XSL шаблоны и специальные скрипты.
Во второй же системе, постоянно, под каждый проект, приходилось дорабатывать модули, а то и ядро, т.к. многие вещи обычными шаблонами просто не реализуешь, нужно было дописывать методы, исправлять существующие.
XSL же позволяет вынести часть логики непосредсвенно в шаблон.
Почему большенство наших производителей CMS против XSL - яснее ясного. Кому хочется ломать и строить заново уже устоявшийся механизм, который стабильно приносит $?
Так вот подход, применяемый в фирме, где система с XSL такой, что имеется законченная коробочная версия продукта, и на базе неё уже делается сайт. Все фичти реализуются "легальными способами", т.е. код системы (ядро, модули) не меняется, меняются только XSL шаблоны и специальные скрипты.
Во второй же системе, постоянно, под каждый проект, приходилось дорабатывать модули, а то и ядро, т.к. многие вещи обычными шаблонами просто не реализуешь, нужно было дописывать методы, исправлять существующие.
XSL же позволяет вынести часть логики непосредсвенно в шаблон.
Почему большенство наших производителей CMS против XSL - яснее ясного. Кому хочется ломать и строить заново уже устоявшийся механизм, который стабильно приносит $?
Еще "недостаток" XSLT в том, что программисты не сразу понимают его, ведь в нем не процедурный подход к программированию.
Я считаю что это лучший шаблонный язык на сегодняшний день.
Я считаю что это лучший шаблонный язык на сегодняшний день.
есть мнение что он не для программистов, а для верстальщиков... но язык действительно уникальный, непохожий ни на один другой, чтобы проникнуть в его суть программистам придется развернуть свой мозг в другую сторону
XSLT - это НЕ шаблонный язык. Это XML, позволяющий делать из одного XML другой XML.
Чтоб эффективно использовать XSLT в качестве языка шаблонизации, нужно включать голову на обоих концах процесса. Поскольку изначально технология создавалась не для этого.
Чтоб эффективно использовать XSLT в качестве языка шаблонизации, нужно включать голову на обоих концах процесса. Поскольку изначально технология создавалась не для этого.
> Это не шаблонный язык вообще.
ок. из xslt: тег-инструкция "xsl:template". как переводится слово "template"?
ок. из xslt: тег-инструкция "xsl:template". как переводится слово "template"?
1) группировка с сортировкой тривиальна, лично для меня таковой планкой полное понимание механизма группировки мюнха.
2) кому как
3) кто ищет тот всегда найдет, есть люди которые активно делятся своим опытом и помогают у обучении новичкам
4) чем вам качество не угодило?
2) кому как
3) кто ищет тот всегда найдет, есть люди которые активно делятся своим опытом и помогают у обучении новичкам
4) чем вам качество не угодило?
из глюков я встречал только два (в Saxon):
1) for-each-group груп не работает со сложным группировочным XPath выражением
2) for-each-group не умеет разбивать блоки текста в группы по br
скорость у XSL нормальная, вот к примеру у меня есть небольшой сайт (примерно 3100 страниц) (для экспериментов по обработке данных) он собирается из одного XML файла (15мб) одним XSL преобразованием примерно за 21с, собирается саксоном, а он не самый быстрый XSL процессор.
думаете на PHP + смарти было бы быстрее?
1) for-each-group груп не работает со сложным группировочным XPath выражением
2) for-each-group не умеет разбивать блоки текста в группы по br
скорость у XSL нормальная, вот к примеру у меня есть небольшой сайт (примерно 3100 страниц) (для экспериментов по обработке данных) он собирается из одного XML файла (15мб) одним XSL преобразованием примерно за 21с, собирается саксоном, а он не самый быстрый XSL процессор.
думаете на PHP + смарти было бы быстрее?
Отмечу, что, расписывая недостатки Smarty, автор статьи не упомянул о реализованной в нём возможности запрета напрямую обращаться к PHP. Детский сад, имхо: "а в Smarty можно запрос к БД в шаблоне прописать", "а в XML можно каталог товаров запихнуть и всё затормозит"... Так сдуру-то можно и сами знаете что сломать :) На мой взгляд, тема в статье раскрыта чересчур однобоко.
Идея правильная, поддерживаю. Действительно, слышал много чего плохого об XSLT, а потом оказывалось, что мнение сформировано не на основе собственного опыта, а по прочтении упомянутой статьи от битриксоидов.
Однако, не со всеми аргументами могу согласиться.
Разделение логики и представления, вообще-то, зависит не только от технологии, но и от просветленности кодера. Умный кодер сделает все как надо хоть на смарти, хоть на шаблонах от phpBB. Глупый кодер и в XSLT такой лес нагородит, что проще будет застрелиться, чем понять полет мысли. Хотя, так уж исторически сложилось, что у нас люди, овладевшие XSLT, в среднем по больнице имеют более высокую квалификацию. Но это - не преимущество технологии. А часть приведенных пунктов, как мне кажется, выдают преимущества подхода "отделяй и влавствуй" за преимущества самого XSLT.
"Безопасность" - притянута за уши, ИМХО. В первую очередь, не следует допускать идиотов до кода, вне зависимости от технологии идиот накосячит. А если вдруг верстальщик действует не по глупости, а из вредительских побуждений - тем более не проблема все испортить - матерное слово в шаблон вставить, например :)
"Нативная поддержка XML" - не совсем в тему. Когда стоит задача преобразования уже предоставленного XML (например, полученного от некоторого удаленного сервиса) - разумеется, XSLT будет оптимальным вариантом, он для этого и сделан. (При этом XSLT-процессор НЕ является "родным парсером XML", как сказано в статье. XSLT делает из одного XML другой XML, и все. Например, распарсить конфиг и передать данные в приложение XSLT не может). В роли средства преобразования XML-документов XSLT не нуждается ни в какой реабилитации. Но к использованию XSLT в качестве шаблонизатора в CMS/CMF это не имеет отношения.
Полутора недель на освоение XSLT, разумеется, не достаточно. Хотя там всего-то десяток употребительных конструкций. Через полторы недели, как правило, верстальщик начинает писать код "как-на-смарти". Ну или как на PHP. Один шаблон, пачка вложенных for-each, ветвление через choose где ни попадя, дублирование кода и прочие радости. Много раз такое видел.
Вообще, не сказано о главном. XSLT сложно сравнивать с другими шаблонизаторами (ну, кроме его самописных модификаций). Сила XSLT - в его декларативности, это принципиально иной подход. Пока кодер мыслит категориями императивного программирования, он не поймет всей прелести XSLT, будет городить for-each'и, ругаясь на синтаксис. Чтоб писать лаконичные, не повторяющиеся, параметризуемые и гибкие шаблоны, нужно научиться думать в таком стиле. Но, ИМХО, оно того стоит.
С другой стороны, использование XSLT предполагает специфическую "инфраструктуру" приложения, а именно - представление документа в виде XML-дерева. От того, как выполняется это действие, многое зависит, здесь есть как большие преимущества, так и большие грабли.
Есть еще пара важных моментов, про которые в статье не сказано.
Во-первых, XML-документ является для верстальщика гораздо более наглядным представлением данных, с которыми он должен работать. Согласитесь, XML можно распечатать, изучить, разобраться в деталях. ИМХО, это гораздо лучше, чем убогая консоль smarty ;) При этом верстальщик понятия не имеет о внутреннем устройстве объектов в приложении. Он видит ТОЛЬКО данные.
Во-вторых, связка XML/XSLT _действительно_ кроссплатформенна. Можно переписать весь проект на другом языке программирования, не трогая при этом ни строчки в шаблонах. А можно отдать трансформацию целиком на клиент. Пока это не слишком реалистично, но перспективы есть.
Однако, не со всеми аргументами могу согласиться.
Разделение логики и представления, вообще-то, зависит не только от технологии, но и от просветленности кодера. Умный кодер сделает все как надо хоть на смарти, хоть на шаблонах от phpBB. Глупый кодер и в XSLT такой лес нагородит, что проще будет застрелиться, чем понять полет мысли. Хотя, так уж исторически сложилось, что у нас люди, овладевшие XSLT, в среднем по больнице имеют более высокую квалификацию. Но это - не преимущество технологии. А часть приведенных пунктов, как мне кажется, выдают преимущества подхода "отделяй и влавствуй" за преимущества самого XSLT.
"Безопасность" - притянута за уши, ИМХО. В первую очередь, не следует допускать идиотов до кода, вне зависимости от технологии идиот накосячит. А если вдруг верстальщик действует не по глупости, а из вредительских побуждений - тем более не проблема все испортить - матерное слово в шаблон вставить, например :)
"Нативная поддержка XML" - не совсем в тему. Когда стоит задача преобразования уже предоставленного XML (например, полученного от некоторого удаленного сервиса) - разумеется, XSLT будет оптимальным вариантом, он для этого и сделан. (При этом XSLT-процессор НЕ является "родным парсером XML", как сказано в статье. XSLT делает из одного XML другой XML, и все. Например, распарсить конфиг и передать данные в приложение XSLT не может). В роли средства преобразования XML-документов XSLT не нуждается ни в какой реабилитации. Но к использованию XSLT в качестве шаблонизатора в CMS/CMF это не имеет отношения.
Полутора недель на освоение XSLT, разумеется, не достаточно. Хотя там всего-то десяток употребительных конструкций. Через полторы недели, как правило, верстальщик начинает писать код "как-на-смарти". Ну или как на PHP. Один шаблон, пачка вложенных for-each, ветвление через choose где ни попадя, дублирование кода и прочие радости. Много раз такое видел.
Вообще, не сказано о главном. XSLT сложно сравнивать с другими шаблонизаторами (ну, кроме его самописных модификаций). Сила XSLT - в его декларативности, это принципиально иной подход. Пока кодер мыслит категориями императивного программирования, он не поймет всей прелести XSLT, будет городить for-each'и, ругаясь на синтаксис. Чтоб писать лаконичные, не повторяющиеся, параметризуемые и гибкие шаблоны, нужно научиться думать в таком стиле. Но, ИМХО, оно того стоит.
С другой стороны, использование XSLT предполагает специфическую "инфраструктуру" приложения, а именно - представление документа в виде XML-дерева. От того, как выполняется это действие, многое зависит, здесь есть как большие преимущества, так и большие грабли.
Есть еще пара важных моментов, про которые в статье не сказано.
Во-первых, XML-документ является для верстальщика гораздо более наглядным представлением данных, с которыми он должен работать. Согласитесь, XML можно распечатать, изучить, разобраться в деталях. ИМХО, это гораздо лучше, чем убогая консоль smarty ;) При этом верстальщик понятия не имеет о внутреннем устройстве объектов в приложении. Он видит ТОЛЬКО данные.
Во-вторых, связка XML/XSLT _действительно_ кроссплатформенна. Можно переписать весь проект на другом языке программирования, не трогая при этом ни строчки в шаблонах. А можно отдать трансформацию целиком на клиент. Пока это не слишком реалистично, но перспективы есть.
полностью согласен) плюсанул бы, но нет такой возможности
упс, что с кодировкой?
«В роли средства преобразования XML-документов XSLT не нуждается ни в какой реабилитации. Но к использованию XSLT в качестве шаблонизатора в CMS/CMF это не имеет отношения.»
Во! Золотые слова.
А основная проблема с XSLT лежит за его пределами - как раз в упомянутом вами представлении документа в формате XML. А защититься от дурака-программиста, к сожалению, намного сложнее, чем от дурака-верстальщика :)
Во! Золотые слова.
А основная проблема с XSLT лежит за его пределами - как раз в упомянутом вами представлении документа в формате XML. А защититься от дурака-программиста, к сожалению, намного сложнее, чем от дурака-верстальщика :)
>Когда стоит задача преобразования уже предоставленного XML (например, полученного от некоторого удаленного сервиса) - >разумеется, XSLT будет оптимальным вариантом, он для этого и сделан.
Не всегда, смотря какое преобразование. Попробуйте например с помощью XSLT преобразовать документ с "плоскими" хедерами
Не всегда, смотря какое преобразование. Попробуйте например с помощью XSLT преобразовать документ с "плоскими" хедерами
в структурированный а-ля XHTML 2.0 ... . Геморой еще тот...
спасибо за этот коммент особенное!
>>Чтоб писать лаконичные, не повторяющиеся, параметризуемые и гибкие шаблоны,
>>нужно научиться думать в таком стиле. Но, ИМХО, оно того стоит.
Научите пож-ста думать в другом стиле!
Я с этой технологией работаю с полгода, и все равно не могу сказать что все "раскурил".
Примеры в сети помогают слабо, приходится порой сильно париться.
Действительно надо перестраивать мышление.
Давно бы кто нибудь завел блог про практический XSLT.
Ау профи!
>>нужно научиться думать в таком стиле. Но, ИМХО, оно того стоит.
Научите пож-ста думать в другом стиле!
Я с этой технологией работаю с полгода, и все равно не могу сказать что все "раскурил".
Примеры в сети помогают слабо, приходится порой сильно париться.
Действительно надо перестраивать мышление.
Давно бы кто нибудь завел блог про практический XSLT.
Ау профи!
Полутора недель на освоение XSLT, разумеется, не достаточно. Хотя там всего-то десяток употребительных конструкций. Через полторы недели, как правило, верстальщик начинает писать код "как-на-смарти". Ну или как на PHP. Один шаблон, пачка вложенных for-each, ветвление через choose где ни попадя, дублирование кода и прочие радости. Много раз такое видел.
для достижения этого уровня достаточно и трех дней...
я видел не один десяток XSLT разработчиков которые достигали этого уровня за 3 дня
иногда люди за три дня успевают разобраться в групперовке
для достижения этого уровня достаточно и трех дней...
я видел не один десяток XSLT разработчиков которые достигали этого уровня за 3 дня
иногда люди за три дня успевают разобраться в групперовке
Пользую Smarty, подумываю пересесть на XSLT, но вот преимущества пока выглядять хлипко. По идее микроскопом и гвозди можно забивать, но лучше всё-таки использовать по назначению. Также и со смарти. Правда вот XML... Если её юзать достаточно активно, то смарти канеш будет не к месту. Пока же я по-старинке всё.
Холивар.
В каментах почему-то все исходят из противопоставления XSLT - Smarty. В то время как и то и другое - крайности, и оба решения имеют массу недостатков. XSLT жутко сырой без примочек типа EXSLT, кроме того требует определенного стиля мышления, и иногда тривиальные задачи там решаются очень нетривиальным способом. Использовать XSLT сложнее чем просто прописать {$var} внутри html (отсюда и зарплата выше), кроме того он требует начальных данных в XML, то есть этот XML еще нужно составить.
А Smarty наборот перегружен ненужными фичами, из-за чего многие соблазняются писать на нем бизнес-логику.
Если уж говорить про php, мой выбор - Blitz или native php.
В каментах почему-то все исходят из противопоставления XSLT - Smarty. В то время как и то и другое - крайности, и оба решения имеют массу недостатков. XSLT жутко сырой без примочек типа EXSLT, кроме того требует определенного стиля мышления, и иногда тривиальные задачи там решаются очень нетривиальным способом. Использовать XSLT сложнее чем просто прописать {$var} внутри html (отсюда и зарплата выше), кроме того он требует начальных данных в XML, то есть этот XML еще нужно составить.
А Smarty наборот перегружен ненужными фичами, из-за чего многие соблазняются писать на нем бизнес-логику.
Если уж говорить про php, мой выбор - Blitz или native php.
А что, МойКруг переписали под XSLT? Там же, вроде, Smarty раньше был.
Отладка шаблона на XSLT, если в нем допущена ошибка, может потребовать от разработчика существенных усилий по ее нахождению и устранению…Большинство описанных в этом абзаце проблем решается вменямым девелопером с хорошим инструментом разработки на раз.
отличная статья!
При переходе на XSLT со Smarty не доволен им был примерно недели полторы-две...
Месяца через два понял, что к Smarty возвращаться нет ни малейшего желания)
По поводу производительности. Имел опыт создания тестов возможности внедрения Smarty в CMS написанный с использованием XML+XSLT и при этом суть XSLT была реализована процентов на 80%-90%. Т.е. можно и лучше - но уже почти то что надо))
Пришел к выводу, что производительность у XSLT и Smarty практически равна.
НО при совершенно различных подходах.
Если использовать подход Smarty в XSLT - тормозит (о чем говорилось в статье)
Но если использовать наоборот - подход XSLT используя Smarty - тормозит еще больше. :)
Кроме того - мне лично гораздо удобнее использовать древовидные структуры - XSLT это работает гораздо быстрее и удобнее.
Ну и опять же "стриктовость" мне нравится очень. Не будет никаких незакрытых тэгов и т.п.
А грамотно форматированный код читать гораздо удобнее, чем такой же смартёвый.
При переходе на XSLT со Smarty не доволен им был примерно недели полторы-две...
Месяца через два понял, что к Smarty возвращаться нет ни малейшего желания)
По поводу производительности. Имел опыт создания тестов возможности внедрения Smarty в CMS написанный с использованием XML+XSLT и при этом суть XSLT была реализована процентов на 80%-90%. Т.е. можно и лучше - но уже почти то что надо))
Пришел к выводу, что производительность у XSLT и Smarty практически равна.
НО при совершенно различных подходах.
Если использовать подход Smarty в XSLT - тормозит (о чем говорилось в статье)
Но если использовать наоборот - подход XSLT используя Smarty - тормозит еще больше. :)
Кроме того - мне лично гораздо удобнее использовать древовидные структуры - XSLT это работает гораздо быстрее и удобнее.
Ну и опять же "стриктовость" мне нравится очень. Не будет никаких незакрытых тэгов и т.п.
А грамотно форматированный код читать гораздо удобнее, чем такой же смартёвый.
Так же и продолжайте писать на Хабре.
Приятная статья, и, что самое страшное, я разделяю большинство Ваших взглядов.
Приятная статья, и, что самое страшное, я разделяю большинство Ваших взглядов.
В своём опыте разработки web - проектов, повидал многое.
Начиная от смеси php+html - как в битриксе например :(, заканчивая своими шаблонами и изобретением велосипеда.
Но пришёл всётаки к xslt.
Скорость работы, говорят некоторые? Честно скажу отличная.
Поддержка? Без проблем.
Разобраться в чужих шаблонах? Поверьте легче, чем к примеру в смарти.
При этом не надо знать php или другие языки, и бояться, что из-за чужого говнакода, вы потрёте глобальную переменную.
Минусы таковы. Всё что есть в интернете и в книгах по xslt, очень тяжело перенести в web.
Там рассказываются о возможностях, абстрактные примеры, спецификации.
А вот с примерами для web проблема.
Проблема и с php. Многие хостеры не любят обновляться. А вот php и libxml - если старые, там есть траблы.
Короче XSLT вещь. И всем советую. Одна проблема, чтобы научится его использовать и учесть многие нюансы, нужно много терпения и времени :( - Поэтому наверное xslt - верстальщики и стоят дорого.
Да совсем забыл. Есть люди увлекающийся типа всё в ООП, всё в функциях, и всё в XML и т.п. Я не фанат такого подхода. И призываю использовать XSLT - там где это нужно.
Начиная от смеси php+html - как в битриксе например :(, заканчивая своими шаблонами и изобретением велосипеда.
Но пришёл всётаки к xslt.
Скорость работы, говорят некоторые? Честно скажу отличная.
Поддержка? Без проблем.
Разобраться в чужих шаблонах? Поверьте легче, чем к примеру в смарти.
При этом не надо знать php или другие языки, и бояться, что из-за чужого говнакода, вы потрёте глобальную переменную.
Минусы таковы. Всё что есть в интернете и в книгах по xslt, очень тяжело перенести в web.
Там рассказываются о возможностях, абстрактные примеры, спецификации.
А вот с примерами для web проблема.
Проблема и с php. Многие хостеры не любят обновляться. А вот php и libxml - если старые, там есть траблы.
Короче XSLT вещь. И всем советую. Одна проблема, чтобы научится его использовать и учесть многие нюансы, нужно много терпения и времени :( - Поэтому наверное xslt - верстальщики и стоят дорого.
Да совсем забыл. Есть люди увлекающийся типа всё в ООП, всё в функциях, и всё в XML и т.п. Я не фанат такого подхода. И призываю использовать XSLT - там где это нужно.
Небольшой вопросик от новичка в XSLT.
А разве сейчас уже три основных браузера не умеют сами, получая связку XML+XSLT, его трансформировать? Потому что я когда я себе тесты делал - именно так и было: был xml с данными и подключенным темплейтом XSLT. XML напрямую отдавался браузерам - а они показывали все так, будто он уже в HTML. То бишь генерация контента отдана клиенту и не тормозит сервер - ибо шаблон статичен, а XML если и динамичен, то уж точно не медленнее, чем если отдавать те же данные в виде HTML.
В общем вопрос тупой - если клиент может рендерить XML+XSLT, нафиг какие-то серверные преобразователи?
А разве сейчас уже три основных браузера не умеют сами, получая связку XML+XSLT, его трансформировать? Потому что я когда я себе тесты делал - именно так и было: был xml с данными и подключенным темплейтом XSLT. XML напрямую отдавался браузерам - а они показывали все так, будто он уже в HTML. То бишь генерация контента отдана клиенту и не тормозит сервер - ибо шаблон статичен, а XML если и динамичен, то уж точно не медленнее, чем если отдавать те же данные в виде HTML.
В общем вопрос тупой - если клиент может рендерить XML+XSLT, нафиг какие-то серверные преобразователи?
Тупой ответ:
делать трансформацию на клиенте - это преступление :)
А если у меня машинка слабенькая то что?
А если у меня Опера 8.0 то что?
А если у меня текстовый браузер то что?
Ничего личного :)
делать трансформацию на клиенте - это преступление :)
А если у меня машинка слабенькая то что?
А если у меня Опера 8.0 то что?
А если у меня текстовый браузер то что?
Ничего личного :)
Делюсь опытом тезисно :)
1. Браузеры умеют рендерить XSLT, по-разному
2. Не все версии браузеров это умеют (к примеру, opera)
3. В мобильных версиях браузеров тоже проблемы
4. До сих пор не знаю, как будет индексироваться такой сайт. (в яндекс, внятно не ответили. больше не писал. может, и умеет)
5. Если xsl'ка не догрузится, мы вообще ничего не увидим
Из плюсов - удобно в ajax'е. Небольшие шаблоны можно использовать и для серверной обработки и грузить на клиенте. Бывает удобно и вообще повторное использование кода это добро.
1. Браузеры умеют рендерить XSLT, по-разному
2. Не все версии браузеров это умеют (к примеру, opera)
3. В мобильных версиях браузеров тоже проблемы
4. До сих пор не знаю, как будет индексироваться такой сайт. (в яндекс, внятно не ответили. больше не писал. может, и умеет)
5. Если xsl'ка не догрузится, мы вообще ничего не увидим
Из плюсов - удобно в ajax'е. Небольшие шаблоны можно использовать и для серверной обработки и грузить на клиенте. Бывает удобно и вообще повторное использование кода это добро.
Тут есть ряд проблем.
1. Индексация поисковиками, как уже было сказано. Возможно, они и сожрут XML, но есть еще один тонкий момент - фактически, получается, что робот и пользователь видят разные данные, а это называется словом "клоакинг", и поисковики такое не любят.
2. Поддержка браузерами. Opera до 9 версии вообще никак не поддерживала. Firefox, например, игнорирует disable-output-escaping, соответственно нет возможности отдавать куски HTML-кода как CDATA.
3. XSLT-шаблон вовсе не обязан быть статичным. В больших проектах с множеством модулей вес шаблона может оказаться весьма большим, поэтому иногда приходится собирать шаблон по частям.
1. Индексация поисковиками, как уже было сказано. Возможно, они и сожрут XML, но есть еще один тонкий момент - фактически, получается, что робот и пользователь видят разные данные, а это называется словом "клоакинг", и поисковики такое не любят.
2. Поддержка браузерами. Opera до 9 версии вообще никак не поддерживала. Firefox, например, игнорирует disable-output-escaping, соответственно нет возможности отдавать куски HTML-кода как CDATA.
3. XSLT-шаблон вовсе не обязан быть статичным. В больших проектах с множеством модулей вес шаблона может оказаться весьма большим, поэтому иногда приходится собирать шаблон по частям.
Вот, кстати, только что наткнулся:
Это из мануала по использованию XSLT в UMI.CMS.
Мне кажется, это отличный пример порочной практики. Когда, вместо использования стандартных средств, разработчики придумывают что-то космическое. Заставляя вникать в то, как устроена их система изнутря, и при том нарушая стройность архитектуры. Ну блин, не должен шаблон решать, показывать ли меню на странице. Шаблон должен содержать средства для отображения меню, если приложение решило, что нужно его отобразить. Я с UMI плотно не работал, может это и удобно в некоторых случаях. Но идеологически выглядит не правильно.
Чего XSLT действительно не хватает - так это функций форматирования даты / времени, и, местами, регулярок. И то, и другое реализовано в exslt, и, кажется, заложено в стандарт 2.0.
А нагружать шаблоны средствами для работы с бизнес-логикой, как это делают UMI (например, в шаблон передаются GET-параметры - ну нафига они там?) - ИМХО, не нужно.
Протоколы UData, UPage, UObject, UFS
Данные протоколы используются xslt-шаблоном для получения данных из БД
на сервере.
Это из мануала по использованию XSLT в UMI.CMS.
Мне кажется, это отличный пример порочной практики. Когда, вместо использования стандартных средств, разработчики придумывают что-то космическое. Заставляя вникать в то, как устроена их система изнутря, и при том нарушая стройность архитектуры. Ну блин, не должен шаблон решать, показывать ли меню на странице. Шаблон должен содержать средства для отображения меню, если приложение решило, что нужно его отобразить. Я с UMI плотно не работал, может это и удобно в некоторых случаях. Но идеологически выглядит не правильно.
Чего XSLT действительно не хватает - так это функций форматирования даты / времени, и, местами, регулярок. И то, и другое реализовано в exslt, и, кажется, заложено в стандарт 2.0.
А нагружать шаблоны средствами для работы с бизнес-логикой, как это делают UMI (например, в шаблон передаются GET-параметры - ну нафига они там?) - ИМХО, не нужно.
>>Ну блин, не должен шаблон решать, показывать ли меню на странице. Шаблон должен содержать средства для отображения меню, если приложение решило, что нужно его отобразить.
Может быть я что не понимаю, или мы говорим о разных "шаблонах"?
Шаблон ничего не должен решать :)
Я ему говорю выведи мне здесь меню - и он выводит :)
А система как раз уже решает какое меню ему вывести, как для зарегистрированного пользователя или как для гостя. И вот этот результат который мне отдает система и проходит через XSLT.
Может быть я что не понимаю, или мы говорим о разных "шаблонах"?
Шаблон ничего не должен решать :)
Я ему говорю выведи мне здесь меню - и он выводит :)
А система как раз уже решает какое меню ему вывести, как для зарегистрированного пользователя или как для гостя. И вот этот результат который мне отдает система и проходит через XSLT.
Ну гляньте документацию по ссылке, будет яснее.
Я как раз и говорю, что шаблон ничего решать не должен, он должен отображать то, что собрала для него система. Т.е. нужно ли собрать меню или какой-либо другой блок - решает система. Максимум, что может шаблон - отображать или не отображать определенный блок. Т.е. в шаблоне можно написать xsl:apply-templates select="someblock", а можно и не писать :) А в документации от UMI описан пример, когда меню не будет собрано, если не попросить об этом в шаблоне при помощи xsl:apply-templates select="document('udata://content/menu')//item". Не знаю, как именно механически устроен протокол udata, но по сути, при помощи него шаблон указывает приложению, что оно должно делать.
Кстати, я подозреваю, что пользователь
lyxsus
Я как раз и говорю, что шаблон ничего решать не должен, он должен отображать то, что собрала для него система. Т.е. нужно ли собрать меню или какой-либо другой блок - решает система. Максимум, что может шаблон - отображать или не отображать определенный блок. Т.е. в шаблоне можно написать xsl:apply-templates select="someblock", а можно и не писать :) А в документации от UMI описан пример, когда меню не будет собрано, если не попросить об этом в шаблоне при помощи xsl:apply-templates select="document('udata://content/menu')//item". Не знаю, как именно механически устроен протокол udata, но по сути, при помощи него шаблон указывает приложению, что оно должно делать.
Кстати, я подозреваю, что пользователь
lyxsusТак давайте расставим точки над "i" и отойдем от UMI.CMS
я создаю шаблон сайта.
Я хочу чтобы именно в правой части у меня выводилось меню - это требование дизайна.
как система поймет что мне выводить его надо именно там?
Я должен в шаблоне указать что именно в этом месте у меня будет выводиться меню сайта.
В вашем случае это вызов идет через конструкцию
<xsl:apply-templates select="document('udata://content/menu')//item" />
Результатом данного запроса будет выданное с учетом прав пользователя xml дерево сайта.
>>при помощи него шаблон указывает приложению, что оно должно делать.
не указывает - а просит систему дать меню если оно есть и пользователя есть на это право :)
А если мне по дизайну не нужно меню?
Зачем мне автоматический лишний запрос в базу?
Если меню нужно по дизайну - оно запрашивается, если нет - то нет:)
С помощью таких запросов я запрашиваю только те данные которые мне нужны, а не то что мне предлагает система.
Если идти по Вашему варианту, где система решает по какому-то там "default" какие данные мне нужны, то большая вероятность их избыточности - мне придется отсекать лишенее.
я создаю шаблон сайта.
Я хочу чтобы именно в правой части у меня выводилось меню - это требование дизайна.
как система поймет что мне выводить его надо именно там?
Я должен в шаблоне указать что именно в этом месте у меня будет выводиться меню сайта.
В вашем случае это вызов идет через конструкцию
<xsl:apply-templates select="document('udata://content/menu')//item" />
Результатом данного запроса будет выданное с учетом прав пользователя xml дерево сайта.
>>при помощи него шаблон указывает приложению, что оно должно делать.
не указывает - а просит систему дать меню если оно есть и пользователя есть на это право :)
А если мне по дизайну не нужно меню?
Зачем мне автоматический лишний запрос в базу?
Если меню нужно по дизайну - оно запрашивается, если нет - то нет:)
С помощью таких запросов я запрашиваю только те данные которые мне нужны, а не то что мне предлагает система.
Если идти по Вашему варианту, где система решает по какому-то там "default" какие данные мне нужны, то большая вероятность их избыточности - мне придется отсекать лишенее.
Да, избыточность действительно порой возникает. Видимо, лично для меня важнее стройность системы.
В моем представлении формированием модульной сетки должен заниматься контроллер. Однако, все знают, что в веб-приложениях очень часто по вполне объективным причинам границы ответственности в рамках MVC весьма призрачны. Так что в данном случае нужно разбираться в архитектуре UMI, с которой, повторюсь, я не слишком хорошо знаком.
Больше всего меня смущает, что шаблон должен обладать информацией о внутреннем устройстве приложения. С другой стороны, если интерфейс запросов в достаточной степени абстрактный, ясный и лаконичный - может это и не страшно. Но только по документации об этом сложно судить, надо смотреть на практике.
В моем представлении формированием модульной сетки должен заниматься контроллер. Однако, все знают, что в веб-приложениях очень часто по вполне объективным причинам границы ответственности в рамках MVC весьма призрачны. Так что в данном случае нужно разбираться в архитектуре UMI, с которой, повторюсь, я не слишком хорошо знаком.
Больше всего меня смущает, что шаблон должен обладать информацией о внутреннем устройстве приложения. С другой стороны, если интерфейс запросов в достаточной степени абстрактный, ясный и лаконичный - может это и не страшно. Но только по документации об этом сложно судить, надо смотреть на практике.
Раз уж заглянул в эту тему — вот мои мысли почти год спустя :)
Много думал над этим вопросом. Пришел к выводу, что сборка модульной сетки — вообще отдельный уровень логики. По очевидным обстоятельствам за этот уровень часто отвечает тот же механизм, что и за шаблонизацию. Получается активный шаблон. Т.е. это 2 разных шаблона: один выводит обвязку (и он может решать, что где подгрузить), второй — всю конкретику. Эти сущности сильно отличаются и логически, и практически (например, видел систему, где модульная сетка формируется мешаниной PHP+HTML, а сами модули шаблонизируются через XSLT).
Я в своих исканиях пошел по другому пути, у меня за сборку модульной сетки отвечает хитрая независимая система правил. Умные люди мне сказали, что это Front Controller :)
Слабое место: эта система должна знать кое-что о дизайне — что у нас есть шапка, левая колонка, правая колонка и т.д., и что при некоторых обстоятельствах обвязка может меняться.
Сильная сторона: эта система может знать гораздо больше о контексте приложения, чем положено знать привычному шаблону. Кроме того, эта система может содержать куски, написанные в императивном стиле (ага, спагетти из if-else), хотя в большинстве случаев хватает декларативных правил. Писать же такую логику на декларативном языке — кощунство и извращение.
Ваш пример с меню — все-таки плохой. Не может быть отображение меню вопросом дизайна. Не может дизайнер сказать: «не буду рисовать меню на этой страничке, оно тут плохо смотрится». Дизайн вторичен, дизайн оформляет то, что по логике приложения должно быть отображено. А логика может быть весьма сложной. В итоге приверженцы «активного шаблона» вынуждены плодить шаблоны под каждый тип страницы, что чревато известными неприятностями.
Много думал над этим вопросом. Пришел к выводу, что сборка модульной сетки — вообще отдельный уровень логики. По очевидным обстоятельствам за этот уровень часто отвечает тот же механизм, что и за шаблонизацию. Получается активный шаблон. Т.е. это 2 разных шаблона: один выводит обвязку (и он может решать, что где подгрузить), второй — всю конкретику. Эти сущности сильно отличаются и логически, и практически (например, видел систему, где модульная сетка формируется мешаниной PHP+HTML, а сами модули шаблонизируются через XSLT).
Я в своих исканиях пошел по другому пути, у меня за сборку модульной сетки отвечает хитрая независимая система правил. Умные люди мне сказали, что это Front Controller :)
Слабое место: эта система должна знать кое-что о дизайне — что у нас есть шапка, левая колонка, правая колонка и т.д., и что при некоторых обстоятельствах обвязка может меняться.
Сильная сторона: эта система может знать гораздо больше о контексте приложения, чем положено знать привычному шаблону. Кроме того, эта система может содержать куски, написанные в императивном стиле (ага, спагетти из if-else), хотя в большинстве случаев хватает декларативных правил. Писать же такую логику на декларативном языке — кощунство и извращение.
Ваш пример с меню — все-таки плохой. Не может быть отображение меню вопросом дизайна. Не может дизайнер сказать: «не буду рисовать меню на этой страничке, оно тут плохо смотрится». Дизайн вторичен, дизайн оформляет то, что по логике приложения должно быть отображено. А логика может быть весьма сложной. В итоге приверженцы «активного шаблона» вынуждены плодить шаблоны под каждый тип страницы, что чревато известными неприятностями.
так точно. я занимаюсь непосредственно проектированием системы.
сейчас объясню, почему работает именно так.
1. По поводу xslt, xml в принципе.
У нас прижился принцип: давать ровно столько данных, сколько необходимо не больше и не меньше. Это продиктовано все той же необходимостью уменьшить размер XML-документа, который необходимо генерить. + еще это достаточно элегантно.
2. Принцип, на котором построены внутренние url-схемы.
Этот подход обусловлен желанием соответствовать идеологии REST.
С этой точки зрения CMS предоставляет набор сервисов. Совсем не важно, как они сгенерировались. Возможно, из кеша, возможно, еще откуда-то. Это неважно. Важно то, что они там есть, что они нужного формата.
И системе тоже неинетерсно, откуда эти сервисы вызываются: через XSLT, из FLASH-версии сайта, через AJAX, через десктопное приложение, и т.д..
Это тот же вариант, что и mash-up. При желании я всегда могу, например объединить список новостей со своего сайта со списком новостей с сайта-сателита. Или брать их из интранет-системы.
Такой подход дает и такое преимущества как:
1. Независимость тестирование. можно тестировать не всю систему, а отдельный сервис. и это наглядно.
2. Если какой-то сервис "отваливается": внутренний или внешний, то это не смертельно.
3. Всякие гаджеты и плагины собираются практически мгновенно. К примеру малополезный, но показательный плагин к firefox'у: http://www.umi-cms.ru/extensions/umi_lic… собран меньше чем за пол часа в процессе изучения плагинов firefox'а.
4. Это поддержка AJAX'а и, наример, флеш-сайтов без лишних движений.
И все эти сервисы учитывают права доступа, и прочее, что у нас делается на бэк-энде.
PS1. Хочу отметить, что внутренние схемы придумали не мы, а подсмотрели у достаточно крутого XSLT-фреймворка.
PS2. Хорошим примером в пользу REST для нас явился google. Не помню, чтобы он когда-либо сильно ошибался в технологическом плане.
сейчас объясню, почему работает именно так.
1. По поводу xslt, xml в принципе.
У нас прижился принцип: давать ровно столько данных, сколько необходимо не больше и не меньше. Это продиктовано все той же необходимостью уменьшить размер XML-документа, который необходимо генерить. + еще это достаточно элегантно.
2. Принцип, на котором построены внутренние url-схемы.
Этот подход обусловлен желанием соответствовать идеологии REST.
С этой точки зрения CMS предоставляет набор сервисов. Совсем не важно, как они сгенерировались. Возможно, из кеша, возможно, еще откуда-то. Это неважно. Важно то, что они там есть, что они нужного формата.
И системе тоже неинетерсно, откуда эти сервисы вызываются: через XSLT, из FLASH-версии сайта, через AJAX, через десктопное приложение, и т.д..
Это тот же вариант, что и mash-up. При желании я всегда могу, например объединить список новостей со своего сайта со списком новостей с сайта-сателита. Или брать их из интранет-системы.
Такой подход дает и такое преимущества как:
1. Независимость тестирование. можно тестировать не всю систему, а отдельный сервис. и это наглядно.
2. Если какой-то сервис "отваливается": внутренний или внешний, то это не смертельно.
3. Всякие гаджеты и плагины собираются практически мгновенно. К примеру малополезный, но показательный плагин к firefox'у: http://www.umi-cms.ru/extensions/umi_lic… собран меньше чем за пол часа в процессе изучения плагинов firefox'а.
4. Это поддержка AJAX'а и, наример, флеш-сайтов без лишних движений.
И все эти сервисы учитывают права доступа, и прочее, что у нас делается на бэк-энде.
PS1. Хочу отметить, что внутренние схемы придумали не мы, а подсмотрели у достаточно крутого XSLT-фреймворка.
PS2. Хорошим примером в пользу REST для нас явился google. Не помню, чтобы он когда-либо сильно ошибался в технологическом плане.
Спасибо за ответ :)
Постараюсь найти время и разобраться, как оно у вас все устроено. Пока, боюсь, мне нечем возразить аргументированно.
REST для меня концепция новая, раньше о ней не слышал, буду изучать. С виду принцип и правда привлекательный, хотя и отличается от всего, к чему я привык. Но есть у меня смутное ощущение, что и трудностей с ним хватает. Придумывать из головы не буду, а если на практике встретится и вспомню про этот топик - отпишусь непременно ;)
Постараюсь найти время и разобраться, как оно у вас все устроено. Пока, боюсь, мне нечем возразить аргументированно.
REST для меня концепция новая, раньше о ней не слышал, буду изучать. С виду принцип и правда привлекательный, хотя и отличается от всего, к чему я привык. Но есть у меня смутное ощущение, что и трудностей с ним хватает. Придумывать из головы не буду, а если на практике встретится и вспомню про этот топик - отпишусь непременно ;)
По поводу все, что кроме GET-параметров, я уже ответил ниже.
Теперь насчет параметров. Я тоже размышлял об их необходимости, и тут достаточно неоднозначно. Зачастую это не нужно.
Если кратко, то параметры могут управлять отображением. Больше особо с ними ничего не сделаешь. Судя по наличию в xslt инструкции "xsl:param", с помощью которой в т.ч. можно передавать параметры в шаблон, так считали и разработчики стандарта. А передать в качестве параметров что-то из get'а вполне разумно. В конце концов шаблон имеет право это знать.
Если бы в xslt можно было использовать переменные (не константы), такую возможность давать было бы действительно небезопасно. :)
Теперь насчет параметров. Я тоже размышлял об их необходимости, и тут достаточно неоднозначно. Зачастую это не нужно.
Если кратко, то параметры могут управлять отображением. Больше особо с ними ничего не сделаешь. Судя по наличию в xslt инструкции "xsl:param", с помощью которой в т.ч. можно передавать параметры в шаблон, так считали и разработчики стандарта. А передать в качестве параметров что-то из get'а вполне разумно. В конце концов шаблон имеет право это знать.
Если бы в xslt можно было использовать переменные (не константы), такую возможность давать было бы действительно небезопасно. :)
Ну дату время можно собственно на уровне обычного кода
отформатировать перед трансформацией… хотя вполне согласен что данной фичи не хватает
Дата парсинг:
geekswithblogs.net/workdog/archive/2007/02/08/105858.aspx
articles.techrepublic.com.com/5100-22_11-5075671.html#CodeExample53
Регулярки в XSLT 2 как вижу есть, хотя ни разу не приходилось пользовать…
www.xml.com/pub/a/2003/06/04/tr.html
отформатировать перед трансформацией… хотя вполне согласен что данной фичи не хватает
Дата парсинг:
geekswithblogs.net/workdog/archive/2007/02/08/105858.aspx
articles.techrepublic.com.com/5100-22_11-5075671.html#CodeExample53
Регулярки в XSLT 2 как вижу есть, хотя ни разу не приходилось пользовать…
www.xml.com/pub/a/2003/06/04/tr.html
Да, я собственно так и делаю — в шаблон отправляется уже оформленная дата. Хотя это неправильно. То, что предлагают по ссылкам — не сильно лучше. Я еще одно время пытался отдавать дату в шаблон в каком-то таком виде:
руководствуясь мыслью, что писать «1 сентября 2009 года» или «01.09.09» — все-таки вопрос дизайна. Но быстро надоело, уж больно громоздко. Есть еще вариант с php:function(), но он не труЪ, ибо проприетарен (exslt тужа же).
Регулярки в XSLT2 радуют (точнее, вообще арсенал работы со строками в новом xpath), не радует туманность перспектив самого XSLT2 для нас — рядовых пыхеров :)
<date day="01" month="09" year="2009" month-name="Сентябрь" month-gen="Сентября" />руководствуясь мыслью, что писать «1 сентября 2009 года» или «01.09.09» — все-таки вопрос дизайна. Но быстро надоело, уж больно громоздко. Есть еще вариант с php:function(), но он не труЪ, ибо проприетарен (exslt тужа же).
Регулярки в XSLT2 радуют (точнее, вообще арсенал работы со строками в новом xpath), не радует туманность перспектив самого XSLT2 для нас — рядовых пыхеров :)
По-моему, в проектах, где используются простые шаблоны, а if/else - это максимально сложная, доступная верстальщику, конструкция, такой сильный инструмент не очень нужен. Вернее, сотруднику нужно обосновать изучение хорошего фолианта по XSLT, которое даст ему только увеличение времени на разработку и поддержку (и, как следствие, рост трудозатрат в целом, на поддержку особенно).
С другой стороны, если речь идет о крупном проекте, над которым работают хорошие профессионалы с золотыми руками - такой подход будет только бонусным.
С другой стороны, если речь идет о крупном проекте, над которым работают хорошие профессионалы с золотыми руками - такой подход будет только бонусным.
xml вообще сложно воспринимается человеком. а шаблоны xslt часто бывают просто нечитаемыми.
стандарт - может быть. удобство - сомнительно.
стандарт - может быть. удобство - сомнительно.
XSLT и Smarty это совсем разные вещи.
Smarty написан на том же php. XSLT отдельная технология. Работает на разных платфорамах и на уровне, выше чем Smarty. Не пойму откуда спор по поводу производительности.
Smarty написан на том же php. XSLT отдельная технология. Работает на разных платфорамах и на уровне, выше чем Smarty. Не пойму откуда спор по поводу производительности.
Еще пару слов в пользу XSLT. Долгое время работал с системой, использующей для отображения XSLT. Не стоит бояться о скорости ее работы. Все работало с хорошим быстродействием – а это была сотни 2 магазинов на одной обычной машинке (P4, 1Gb, IDE), по посещаемости весьма приблизительно – по 200 хостов на сайт в день.
Все зависит от того как построить систему. Если генерировать каждую страницу на запрос, к тому же каждый раз для этого строить немаленькую XML – то естественно будут проблемы с производительностью.
Но если хорошо построен механизм кэширования. Как на уже сформированный HTML, к примеру, так еще и кэшировать XML для отдельных объектов, с которых потом быстро можно собрать XML для страницы. Нагрузка на подсистему генерации страниц будет небольшая.
При этом получаем удобство XSLT. Например, подумайте как бы вы реализовали вывод названия товаров на странице, отсортированных по алфавиту, из списка товаров на странице. В XSLT – пара строчек, а на том же Smarty без дописывания кода на PHP уже не обойдетесь.
И еще один момент – вы можете позволить менять шаблоны кому угодно, и он не сможет что-либо испортить в системе, получить доступ к коду той же CMS (что удобно, если вы не хотите открывать ее код).
Все зависит от того как построить систему. Если генерировать каждую страницу на запрос, к тому же каждый раз для этого строить немаленькую XML – то естественно будут проблемы с производительностью.
Но если хорошо построен механизм кэширования. Как на уже сформированный HTML, к примеру, так еще и кэшировать XML для отдельных объектов, с которых потом быстро можно собрать XML для страницы. Нагрузка на подсистему генерации страниц будет небольшая.
При этом получаем удобство XSLT. Например, подумайте как бы вы реализовали вывод названия товаров на странице, отсортированных по алфавиту, из списка товаров на странице. В XSLT – пара строчек, а на том же Smarty без дописывания кода на PHP уже не обойдетесь.
И еще один момент – вы можете позволить менять шаблоны кому угодно, и он не сможет что-либо испортить в системе, получить доступ к коду той же CMS (что удобно, если вы не хотите открывать ее код).
Имхо, XSLT - отличная вещь, но чтоб внедрять ее в реальные проекты для реальных заказчиков за реальные $$$ надо 3-4 проекта сделать некоммерчиских, чисто для изучения технологии. А это зачастую слишком долго.
При упоминании XSLT у меня в горле встает комок примерно того же размера, что при упоминании о регулярках. И то и то хорошо, но ты в этом либо спец с опытом, либо ничего.
При упоминании XSLT у меня в горле встает комок примерно того же размера, что при упоминании о регулярках. И то и то хорошо, но ты в этом либо спец с опытом, либо ничего.
Имхо, быть пластическим хирургом - отличная вещь, но чтобы получать за одну операцию по несколько тыщ $$$ надо лет 7-10 учиться и практиковаться ;)
Вам не кажется, что дело не в XSLT, а просто мир так устроен? ;)
Вам не кажется, что дело не в XSLT, а просто мир так устроен? ;)
Да, именно так мир и устроен. Но ваша аналогия немного не в ту степь :-) Много пластических хирургов никому нафиг не надо ), а здесь людей манят на то чтоб все тратили драгоценное время для улучшения своего дзена. И это хорошо, вопрос лишь если я выучу XML/XSLT и начну внедрять в проекты, как мне заставить учить его других сотрудников и кто за это платит?
не волнуйтесь, много спецов на IT рынке в ближайшие несколько десятилетий не будет точно.
вообще, много спецов нигде не бывает.
по поводу "что мне за это будет". есть абсолютно рациональные и эгоистичные причины для разработчика, они названы в тексте и в комментах. так что никого заставлять не надо.
насчет "кто платит" - если изучите рынок вакансий, увидите, что платежеспособный спрос на кодеров с xslt велик и платят на 30-50% больше.
вообще, много спецов нигде не бывает.
по поводу "что мне за это будет". есть абсолютно рациональные и эгоистичные причины для разработчика, они названы в тексте и в комментах. так что никого заставлять не надо.
насчет "кто платит" - если изучите рынок вакансий, увидите, что платежеспособный спрос на кодеров с xslt велик и платят на 30-50% больше.
Ну что ж, поживем - увидим. Пока что я хочу изучить питон и его платежеспособный рынок (количество, на самом деле, пофиг, главное чтоб не ниже планки) по сравнению с пхп, так как последний надоел. Думаю через пол годика уже полностью на питон пересесть.
А XML/XSLT когда-то применял, сейчас не скажу что проекты со smarty и простых шаблонизаторах при правильной проектировке плохи. Никакого вмешательства в бизнес-логику и так далее нету.
Единственное что действительно сейчас пригодилось бы - клиент-обработка шаблона. Вот это рулит на высоконагрузочном проекте где шаблонизатор пыхтит.
А XML/XSLT когда-то применял, сейчас не скажу что проекты со smarty и простых шаблонизаторах при правильной проектировке плохи. Никакого вмешательства в бизнес-логику и так далее нету.
Единственное что действительно сейчас пригодилось бы - клиент-обработка шаблона. Вот это рулит на высоконагрузочном проекте где шаблонизатор пыхтит.
Библиотека libxslt, которую удобно в Python использовать, гораздо лучше чем трансформер в PHP, который работает с ошибками, и в котором функции расширения реализованы через одно место.
Синтаксис XSLT это не меняет :-)
В PHP меняет, т.к. некоторые вещи не работают, это касается в большей мере XPath. Именно поэтому мой выбор пал на питон, а то выбрал бы PHP, т.к. он более распространен.
А что за некоторые вещи, если не секрет?
Я уже не помню детали, коллеги, программирующие на PHP, постоянно меняют решение задачи, т.к. некоторые XPath просто не работают, специально проверяли на других трансформерах, решения были рабочими. Еще хороший трансформер, полностью поддерживающий стандарт, в .Net, хотя самый быстрый (и на сегодняшний день даже вроде) это msxsl.
В общем, если будут детали - с радостью посмотрю и потестирую проблемы с XSLT в PHP. У меня какие-то тоже были, но их решили быстро помню.
Про msxsl не слыхал, но сдается мне, это что-то с MS связано, и скорее всего для меня оно не существует под линухами.
Про msxsl не слыхал, но сдается мне, это что-то с MS связано, и скорее всего для меня оно не существует под линухами.
в php использовал xml& xslt. были некоторые проблемы ( не работала функция index-of(),empty(),..) с xpath. но пенять особо не на кого, т.к. dom в php хоть и относительно давно, но все равно не полностью поддерживается и не очень стабилен. хорошо, что хоть наиболее распространённые функции реализованы.
решал проблему альтернативными xpath запросами. иногда полученное решение теряло изящность технологии,имхо.
решал проблему альтернативными xpath запросами. иногда полученное решение теряло изящность технологии,имхо.
а что в PHP нельзя libxslt использовать? я первый раз слышу про трансформер в PHP, который работает с ошибками... я всегда думал что кроме libxslt в php ничего другого и не используют
советую посмотреть сюда
При разработке проектов для клиентов компании и для самой компании мы в свое время столкнулись с тем, что использовать "шаблоны" APS.NET опасно для психики и для проектов.
Идею использовать XML+XSLT в качестве движка шаблонов подсказал небольшой проектик, надо было прилепить еще старое Google Search API, которое было в виде SOAP Web Service.
Получить XML от веб-сервиса, сделать трансформацию и на выходе получить красивую страниу с результатами поиска.
Разобравшись с технологией, оказалось, что MS SQL замечательно возвращает результаты запросов в виде XML, C# получает XML, делает трансформацию. В итоге весь код занимает пару строчек. Для AJAXa можно использовать трансформацию на клиенской стороне. Встроеный набор функий XSLT можно раширять за счет написания функций на C# - ms-xslt это поддерживает.
Все очень красиво, элегантно, читабельно.
Автору спасибо за тему - я думала мы одиноки в использовании этой технологии.
Идею использовать XML+XSLT в качестве движка шаблонов подсказал небольшой проектик, надо было прилепить еще старое Google Search API, которое было в виде SOAP Web Service.
Получить XML от веб-сервиса, сделать трансформацию и на выходе получить красивую страниу с результатами поиска.
Разобравшись с технологией, оказалось, что MS SQL замечательно возвращает результаты запросов в виде XML, C# получает XML, делает трансформацию. В итоге весь код занимает пару строчек. Для AJAXa можно использовать трансформацию на клиенской стороне. Встроеный набор функий XSLT можно раширять за счет написания функций на C# - ms-xslt это поддерживает.
Все очень красиво, элегантно, читабельно.
Автору спасибо за тему - я думала мы одиноки в использовании этой технологии.
когда я над сайтами МТС работал, то там всё висело под парсером и на XSL шаблонах.
не люблю XSLT, но должен признать - лучшего шаблонизатора я ещё не встречал в просторах всемирной...
не люблю XSLT, но должен признать - лучшего шаблонизатора я ещё не встречал в просторах всемирной...
Непонятно как вообще битрукс может наезжать по xml/xslt, их тварение чудовищно, оно убыточно и место ему на серверах типа Народ.ру. Если бы не туролобость и глупость менеджеров то битрукс никода бы не стал "лидером".
Что касаемо XML/XSLT то здесь не может быть проблем, надо признать что для применения его в промышленных маштабах нужно в цепочку програмист верстальщик вклинить еще одного человека js xml xslt програмиста, тогда дело пойдет совсем по другому, обычный пхп програмист не всегда способен воспринять логику xml есму проще поставить 20 проверок чем думать об базе глобально так же как и верстальщик недостаточно развит как правило до xml.
php активно работает над парсером и с каждым выпуском дело идет к лучшему.
Что касаемо XML/XSLT то здесь не может быть проблем, надо признать что для применения его в промышленных маштабах нужно в цепочку програмист верстальщик вклинить еще одного человека js xml xslt програмиста, тогда дело пойдет совсем по другому, обычный пхп програмист не всегда способен воспринять логику xml есму проще поставить 20 проверок чем думать об базе глобально так же как и верстальщик недостаточно развит как правило до xml.
php активно работает над парсером и с каждым выпуском дело идет к лучшему.
Браво. То, что я понимал лишь инстинктивно вы виртуозно разложили по полочкам. Я хочу быть вашим другом. :)
На счет сложности отладки с вами я только не соглашусь. Любой xslt-процессор (xsltproc) махом выдаст вам в каком месте ошибка.
На счет сложности отладки с вами я только не соглашусь. Любой xslt-процессор (xsltproc) махом выдаст вам в каком месте ошибка.
Что значит "в чистом виде"? Это что за формат данных такой? В большинстве трансформеров XSLT можно использовать функции расширения, вот и передавайте в эту функцию SQL-запрос, и получайте на выходе XML, который тут же можно обработать средствами XSLT.
Выгрузка данных из MySQL в XML это не больше одной страницы кода на любом удобном для вас языке программирования, при этом в удобном для шаблонизатора формате. MSSQL может выгружать в XML данные, но не всегда это удобно, т.к. обязательно не будет хватать какой-нибудь мелочи, навроде парсинга даты.
Выгрузка данных из MySQL в XML это не больше одной страницы кода на любом удобном для вас языке программирования, при этом в удобном для шаблонизатора формате. MSSQL может выгружать в XML данные, но не всегда это удобно, т.к. обязательно не будет хватать какой-нибудь мелочи, навроде парсинга даты.
Я не придираюсь, просто для любого шаблонизатора данные придется в какой-либо формат преобразовывать. Я пользовался следующими трансформерами: msxsl3, msxsl4 (или msxml3/4???), трансформер из .net 1.1, и libxslt из питона. Все они работают довольно быстро, разве что .net-овский кушает много памяти при большом XSLT, необходима оптимизация.
Без операции преобразования не обойтись, даже если база будет выгружать в XML, все равно кто-то будет этим заниматься. И если поступать по умному - не выгружать все данные, а лишь те, что нужны на веб-странице, то расходы на работу с XML будут минимальны, и скорость будет сопоставима с другими шаблонизаторами.
Я в данный момент для формирования XML из базы использую libxml2 - данные сразу формируются в DOM, и потом "натравливаю" на них XSLT-трансформацию. SQL-запросы более медленная операция из всех других, так что оптимизацию по скорости надо делать в другом месте.
Без операции преобразования не обойтись, даже если база будет выгружать в XML, все равно кто-то будет этим заниматься. И если поступать по умному - не выгружать все данные, а лишь те, что нужны на веб-странице, то расходы на работу с XML будут минимальны, и скорость будет сопоставима с другими шаблонизаторами.
Я в данный момент для формирования XML из базы использую libxml2 - данные сразу формируются в DOM, и потом "натравливаю" на них XSLT-трансформацию. SQL-запросы более медленная операция из всех других, так что оптимизацию по скорости надо делать в другом месте.
Никто не привел никаких примеров.
Вот пример бесплатного форума который работает на XSL, причем поддерживает и сервернюу и клиентскии трансформацию:
http://www.demozzz.com/orca/demo/?xsl_mode=server
http://www.demozzz.com/orca/demo/?xsl_mode=client
Вот пример бесплатного форума который работает на XSL, причем поддерживает и сервернюу и клиентскии трансформацию:
http://www.demozzz.com/orca/demo/?xsl_mode=server
http://www.demozzz.com/orca/demo/?xsl_mode=client
В данный момент как раз работаю над созданием доски объявлений, там очень много повторяющихся щаблонов с небольшими отличиями, попробовал применить XML/XSLT, очень понравилось! Производительность на уровне, а если кэшировать грамотно, то вообще супер, количество кода сократилось раз в 7, 8! Единственный "минус" пришлось потратить время на изучение X-технологий!
Хочется верить, что XSLT станет популярнее с появлением специального вычислительного облака под него. Там была бы поддержана лишь одна СУБД хранящая все данные в массиве xml-файлов, ну и язык поддерживался бы только один — XSLT.
Язык хорош тем, что прост при всей мощности в реализации бизнес-логики, но его хочется обрамить более комфортной СУБД (коммент выше про это), ну и облачным удобством, что бы было как в Heroku или в нашем dokkur.com.
Стараюсь реализовать это в рамках проекта «формуляр» (https://github.com/m8data/formulyar).
Язык хорош тем, что прост при всей мощности в реализации бизнес-логики, но его хочется обрамить более комфортной СУБД (коммент выше про это), ну и облачным удобством, что бы было как в Heroku или в нашем dokkur.com.
Стараюсь реализовать это в рамках проекта «формуляр» (https://github.com/m8data/formulyar).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Реабилитация XML/XSLT технологий