Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 101
Спасибо! Интересно изложили..
Отлично, как давно я искал такой мануал. Всё по делу и ничего лишнего. Огромное спасибо!
Спасибо, хорошая статья!
Мне во многих проектах доводилось плотно заниматься xsl-трансформацией. За это время накопились несколько замечаний, которые стоит учесть при выборе этой технологии.
1. тормозит
Нельзя сказать, что безумно, но если дело доходит до оптимизации скорости ответа сервера — xsl-трансформация окажется одним из самых «узких» мест. Можно писать «правильные» шаблоны и со временем научиться «разгонять» скорость их обработки. Но значительного прироста в скорости это не принесет. В последнем проекте это сыграло решающую роль и пришлось отказаться от xsl вообще.
2. нет четкой структуры. В случае большого объема кода приходится изобретать и постоянно придерживаться четких правил для вложенности шаблонов. Встроенных средств для этого нет.
3. верстальщики не знают xsl. Это заметно осложняет последующую поддержку проекта.
Мне во многих проектах доводилось плотно заниматься xsl-трансформацией. За это время накопились несколько замечаний, которые стоит учесть при выборе этой технологии.
1. тормозит
Нельзя сказать, что безумно, но если дело доходит до оптимизации скорости ответа сервера — xsl-трансформация окажется одним из самых «узких» мест. Можно писать «правильные» шаблоны и со временем научиться «разгонять» скорость их обработки. Но значительного прироста в скорости это не принесет. В последнем проекте это сыграло решающую роль и пришлось отказаться от xsl вообще.
2. нет четкой структуры. В случае большого объема кода приходится изобретать и постоянно придерживаться четких правил для вложенности шаблонов. Встроенных средств для этого нет.
3. верстальщики не знают xsl. Это заметно осложняет последующую поддержку проекта.
1. Для того чтобы не тормозило надо использовать кеширование.
2. Четких правил придерживаться стоит всегда.
3. Плохие верстальщики не хотят знать XSL. Хороших можно научить.
2. Четких правил придерживаться стоит всегда.
3. Плохие верстальщики не хотят знать XSL. Хороших можно научить.
Согласен по всем пунктам, однако:
1. действительно это один из способов «разгона», но если страница на 100% динамическая — помогает мало.
2. это гораздо удобней делать, когда правила встроены в технологию или даже диктуются на уровне синтаксиса.
3. к сожалению кадровой политикой везде занимались другие люди и большого выбора верстальщиков не было.
Да вобщем-то верстальщиков тоже можно понять — они шли верстать макеты в хтмл, ну максимум править шаблоны очень похожие на хтмл, а сложный хсл шаблон достаточно далек от результирующего хтмл'я.
И кстати, «я за наших!» т.е. мне нравится xsl и интересно было с ним работать. Но есть моменты на которые необходимо обратить внимание при выборе технологии. Т.к. отказаться от xsl, когда проект уже практически готов будет очень сложно.
1. действительно это один из способов «разгона», но если страница на 100% динамическая — помогает мало.
2. это гораздо удобней делать, когда правила встроены в технологию или даже диктуются на уровне синтаксиса.
3. к сожалению кадровой политикой везде занимались другие люди и большого выбора верстальщиков не было.
Да вобщем-то верстальщиков тоже можно понять — они шли верстать макеты в хтмл, ну максимум править шаблоны очень похожие на хтмл, а сложный хсл шаблон достаточно далек от результирующего хтмл'я.
И кстати, «я за наших!» т.е. мне нравится xsl и интересно было с ним работать. Но есть моменты на которые необходимо обратить внимание при выборе технологии. Т.к. отказаться от xsl, когда проект уже практически готов будет очень сложно.
Плох тот верстальщик, который не хочет научиться большему ) Я вобще против такой профессии. Более уместно будет Front-End Web Developer, тут даже само название обязывает знать больше чем просто верстка. )
А в плане технологий - все просто и неоднократно оговорено. Технологию надо выбирать в зависимости от нужд проекта, а не в зависимости от самой технологии. Это как "php-программист" )
А в плане технологий - все просто и неоднократно оговорено. Технологию надо выбирать в зависимости от нужд проекта, а не в зависимости от самой технологии. Это как "php-программист" )
не нужно решать за людей чему им учиться.
человек имеет право решать - нужно ему это или нет.
знания xsl скорее нужны девелоперу, и как результат, грамотного верстальщика может просто не оказаться под рукой когда он нужен ( девелоперы обычно заняты на 120%)
человек имеет право решать - нужно ему это или нет.
знания xsl скорее нужны девелоперу, и как результат, грамотного верстальщика может просто не оказаться под рукой когда он нужен ( девелоперы обычно заняты на 120%)
Во-первых вы невнимательно прочитали мой комментарий. Девелоперы тоже делятся на Front-End и Back-End.
Во-вторых вы видимо не имели дело с XSLT. Никто при разработке больших проектов не будет верстать все в статике, а затем просить "девелопера" переводить все на XSLT-шаблоны. Это бессмысленая трата времени.
XSLT имеет самое прямое отношение к верстке и является частью Front-End'a.
Кроме того, я ни за кого ничего не решаю, каждый сам себе Прокруст. И вы, пожалуйста не решайте, что мне говорить, а чего не стоит.
Во-вторых вы видимо не имели дело с XSLT. Никто при разработке больших проектов не будет верстать все в статике, а затем просить "девелопера" переводить все на XSLT-шаблоны. Это бессмысленая трата времени.
XSLT имеет самое прямое отношение к верстке и является частью Front-End'a.
Кроме того, я ни за кого ничего не решаю, каждый сам себе Прокруст. И вы, пожалуйста не решайте, что мне говорить, а чего не стоит.
Никто при разработке больших проектов не будет верстать все в статике, а затем просить "девелопера" переводить все на XSLT-шаблоны.
Мне кажется это разного плана задачи - одно дело отладить сверстанный дизайн под все браузеры, другое дело связать с бекэндом.
На счет больших проектов - вы не поверите что там происходит :) Там и HTML в базу кладут и еще похлеще вытворяют. Знаю, участвовал и да сих пор общаюсь с людьми, которые делают проекты для Билайна, Боинга и других крупных корпораций.
Далее, "не будет верстать все в статике, а затем просить "девелопера" переводить все на XSLT-шаблоны".
Простите, а Вы стадию прототипирования начисто игнорируете? И frontend и backend "по-живому" делаете? Не хочу в это верить, боюсь я таких людей :)
Ну и по последнему - я не указываю Вам, тут все выражают мнение. Обратите внимание, я как раз и писал о том что каждый выбирает сам. Это Вы пытаетесь указать "Плох тот верстальщик, который не хочет научиться большему", что как я вижу есть принуждение.
P.S. XSLT нужно применять осторожно и с умом. И только когда это оправдано.
Далее, "не будет верстать все в статике, а затем просить "девелопера" переводить все на XSLT-шаблоны".
Простите, а Вы стадию прототипирования начисто игнорируете? И frontend и backend "по-живому" делаете? Не хочу в это верить, боюсь я таких людей :)
Ну и по последнему - я не указываю Вам, тут все выражают мнение. Обратите внимание, я как раз и писал о том что каждый выбирает сам. Это Вы пытаетесь указать "Плох тот верстальщик, который не хочет научиться большему", что как я вижу есть принуждение.
P.S. XSLT нужно применять осторожно и с умом. И только когда это оправдано.
Я хорошо знаю что происходит в больших проектах, так как принимаю в них непосредственное участие. И думаю что все зависит от компании и работников.
Backend'ом я не занимаюсь, а frontend сразу начинаю с XSLT, это гораздо удобнее, по крайней мере в моей компании. Прототипирование здесь не причем. Это более ранняя стадия.
Если вы считаете что мои слова - принуждение, то скажу более глобально. Плох тот разработчик, который не хочет учиться чему-то новому. Разработчика, который считает что он уже все знает, надо гнать в шею.
По поводу технологий согласен и повторюсь. Цель определяет средства, а не наоборот.
Backend'ом я не занимаюсь, а frontend сразу начинаю с XSLT, это гораздо удобнее, по крайней мере в моей компании. Прототипирование здесь не причем. Это более ранняя стадия.
Если вы считаете что мои слова - принуждение, то скажу более глобально. Плох тот разработчик, который не хочет учиться чему-то новому. Разработчика, который считает что он уже все знает, надо гнать в шею.
По поводу технологий согласен и повторюсь. Цель определяет средства, а не наоборот.
Правильная позиция. Нет смысла плодить узких специалистов. Пусть специалист будет узким пока он ничего не умеет. А с таким подходом специалисты не хотят ничему учиться, потому что это не их область, они, видите ли пришли на html-верстальщиков.
Я верстальщик с двухлетним стажем, очень жажду изучить XSL, но на работе так заваливают рутино, что времени вообще ноль.
Почитайте http://www.zvon.org/xxl/XSLTutorial/Outp…
Мне хватило недели, чтобы разобраться.
Мне хватило недели, чтобы разобраться.
хм, забавно... через полгода работы с XSLT 2.0 (Saxon) я понял что я бог и могу делать на нем все, через год до меня дошло что я не знаю ключевых моментов даже XSLT 1.0, через полтора я каждый раз сомневаюсь в разумности использования той или иной конструкции, и каждый день сулит все новые и новые открытия, и день когда я скажу что разобрался с XSLT по-моему никогда не наступит...
впрочем, это исключительно проблемы моего собственного мозга, у вас конечно все получится намного быстрее)
впрочем, это исключительно проблемы моего собственного мозга, у вас конечно все получится намного быстрее)
Уже ничего на этом сервере нет, на главной высвечивается - "It works!", надеюсь что временно.
не знаю, что у вас за шаблоны, но свои я оцениваю как достаточно сложные (потому как результирующее DOM дерево после формирования еще раз обрабатываеся внутри xslt, но и не только) и формирование документа из моего шаблона занимает от одной до четырех сотых секунды. шаблоны все в распарсенном состоянии хранятся в памяти, системы - suse linux 10.1 на pentium d 2.8 GHz и mac os x 10.5 на core 2 duo 2.33 GHz, везде последние libxml2 & libxslt
3. Плохие верстальщики не хотят знать XSL. Хороших можно научить.
Сейчас верстальщики все еще не знают XSL)
Верстальщики не знают ничего кроме верстки, всему надо учить, и лучше один раз научить XSLT.
спасибо за статью!
было бы очень удобно скачать все файлы статьи одним архивом... хотя бы открыть в любимом xslt-редакторе (подсветка, навигация и т.п.)
было бы очень удобно скачать все файлы статьи одним архивом... хотя бы открыть в любимом xslt-редакторе (подсветка, навигация и т.п.)
Собрал из того, что было:
http://parser.proc.ru/iso/xslt-1.zip
В шаблоне все пути прописаны от корня (делал на основе шаблона работающего на реальном сайте) поэтому либо перепишите их на относительные либо запускайте из под Apache.
В архиве входной XML-документ лежит в /xsl/document.xml
http://parser.proc.ru/iso/xslt-1.zip
В шаблоне все пути прописаны от корня (делал на основе шаблона работающего на реальном сайте) поэтому либо перепишите их на относительные либо запускайте из под Apache.
В архиве входной XML-документ лежит в /xsl/document.xml
Спасибо, интересно, подробно и познавательно! Классная статья.
Но только одно замечание - вы забыли, как и все сторонники хслт, о самом важном вопросе, а именно: "нахрена козе баян?"
Система тратит время как на составление хмля, так и на его же парсинг, а где же плюсы? Каково принципиальное отличие от тех же пхпшных шаблонизаторов, от того же популярного смарти?
Но только одно замечание - вы забыли, как и все сторонники хслт, о самом важном вопросе, а именно: "нахрена козе баян?"
Система тратит время как на составление хмля, так и на его же парсинг, а где же плюсы? Каково принципиальное отличие от тех же пхпшных шаблонизаторов, от того же популярного смарти?
Цель статьи ответить на вопрос: Как? а не Зачем.
Не смешите, хотите сказать, что смарти отличается большой производительностью?
Каково принципиальное отличие от тех же пхпшных шаблонизаторов, от того же популярного смарти?
приниципальное - трансформации можно гонять на клиенте а не на сервере ;)
хотя на практике мало кто этим пользуется...
XSLT дает очередную возможность отделения мух от котлет, притом полную, сам стараюсь работать только с xslt, простейший пример: есть XML и его можно вывести как заполненную форму так и просто как два дива, плюс при выводе вида не надо заморачиваться с экранированием спец символов.
P.S. Русские примеры xml/xpatch/xslt немного посеченгная версия английской версии. И, по хорошему, кучу нюансов эти примеры не отражают, искал в свое время некоторые решения по маленьким кусочкам, так что куча документации - это громкие слова
P.S. Русские примеры xml/xpatch/xslt немного посеченгная версия английской версии. И, по хорошему, кучу нюансов эти примеры не отражают, искал в свое время некоторые решения по маленьким кусочкам, так что куча документации - это громкие слова
спасибо, за статью, есть вопросик - почему именно шаблоны lang, как мне кажется в случае локализации лучше всего поможет именно dtd?
В настоящее время у меня для разных языков используются специальные xsl-таблицы. С ними проще работать чем с DTD. Кроме того, я сейчас пытаюсь перевести все на динамические XSL-шаблоны, которые формируются индивидуально для каждого пользователя.
не вижу особых проблем написать в dtd <!ENTITY site.about.title "Привет мир">,
а потом в шаблоне <xsl:text>&site.about.title</xsl:text>, а каким образом Вы делаете вызов разных таблиц для разных локалей, через call-template или apply-template?
а потом в шаблоне <xsl:text>&site.about.title</xsl:text>, а каким образом Вы делаете вызов разных таблиц для разных локалей, через call-template или apply-template?
<xsl:template match="/node()"> </xsl:template> - шаблон для элемента /node() (корневого). Вместо /node() можно указать //document, т.к. он у нас являеться корневым узлом.меня немного пугают используемые вами xpath-выражения, если вы хотите взять корневой элемент почему бы не сделать это хотя бы так match="/document", во втором случае (//document) процессор не остановится на первом элементе, а продолжит бежать по всему дереву в поисках элемента document, а оно вам надо? старайтесь использовать // как можно реже, вы теряете в производительности
У меня используется /node().
//document я указал, т.к. /document подглючивал у меня сегодня в IE.
Насчет // - согласен.
//document я указал, т.к. /document подглючивал у меня сегодня в IE.
Насчет // - согласен.
лично для себя я считаю хорошей практикой начинать с корня
а дальше уже обращаться ко всем элементам самым простым способом
но это уже каждый сам для себя решает, что хорошо, а что плохо)
<xsl:template match="/">
<xsl:apply-templates />
</xsl:template>
а дальше уже обращаться ко всем элементам самым простым способом
<xsl:template match="document">
...
</xsl:template>
но это уже каждый сам для себя решает, что хорошо, а что плохо)
Подходит для относительно небольших страниц, на которых в основном статический контент. Если что-то больше - лучше использовать native php или шаблонизатор на компилируемом языке, например Си.
Идеология очень хороша, практикую уже 2 года. Но есть проблема: шаблонизированные формы, т.е. элементы form, которые обёрнуты в шаблон XSLT. Так вот, при отправке методом POST, поля такой формы не передаются серверу из Opera. Из FF и IE передаются, но исключительно в UTF-8, какой-бы чарсет ни был установлен.
Если кто-нибудь разобрался с этим, пожалуйста, поделитесь решением.
Если кто-нибудь разобрался с этим, пожалуйста, поделитесь решением.
Странно. Попробуйте зайти на http://parser.proc.ru/forum/ (там все на XSLT)
Я оперой давно не пользуюсь, поэтому скатать четко не могу, но проблем быть не должно.
Я оперой давно не пользуюсь, поэтому скатать четко не могу, но проблем быть не должно.
Решение есть такое:
<xsl:output method="xml"
...
/>
Именно из-за этого я делаю один шаблон для Оперы и еще один для остальных браузеров.
Ну а вообще в Опере 9.5 это уже поддерживается.
<xsl:output method="xml"
...
/>
Именно из-за этого я делаю один шаблон для Оперы и еще один для остальных браузеров.
Ну а вообще в Опере 9.5 это уже поддерживается.
насчет node() я писал немного выше - я не утверждаю, что так и надо. Просто мне пока так удобнее читать: выбираем корневой узел.
Про
Насчет ul id="main-menu" - эта конструкция более валидная, чем
Про
<xsl:variable name="current-section" select="/*/@id" /> я постараюсь поговорить позже. Это действительно удобнее. Просто, нужно будет еще объяснить переменные XSL.Насчет ul id="main-menu" - эта конструкция более валидная, чем
<menu>В чем преимущество парсинга при помощи браузера? А в том, что пользователь один раз загрузит xsl-шаблон для страницы (т.е. по сути всю разметку) и потом будет подгружать только данные из xml. Работает это очень и очень быстро.
Минуса два. Первый - это то, что постоянно сталкиваешься с тем, что в каком-нибудь браузере что-то из xslt не реализовано. Конечно, чаще всего этим браузером становится Опера:) И второй минус - Яндекс не индексирует сделанные таким образом сайты. Т.е. бот заходит, но не индексирует. В чем проблема - пока не знаю. Буду очень признателен, если кто-нибудь поделится своим опытом в этой связи.
Минуса два. Первый - это то, что постоянно сталкиваешься с тем, что в каком-нибудь браузере что-то из xslt не реализовано. Конечно, чаще всего этим браузером становится Опера:) И второй минус - Яндекс не индексирует сделанные таким образом сайты. Т.е. бот заходит, но не индексирует. В чем проблема - пока не знаю. Буду очень признателен, если кто-нибудь поделится своим опытом в этой связи.
Дак в том-то и дело. Что я сделал выходной xml-файл так, что он выглядит как обычный html со всеми head, body. Ни одного не-html-ного тега нет. Только в начале да подключается xsl.
Т.е. я сделал тупо текстовую версию сайта со всеми ссылками, переходами. Гугл захавал - я смотрю в кеше и вижу то, что и задумывал. Но вот яндекс, зараза...
Т.е. я сделал тупо текстовую версию сайта со всеми ссылками, переходами. Гугл захавал - я смотрю в кеше и вижу то, что и задумывал. Но вот яндекс, зараза...
Возможно дело в Content-Type, Яндекс не хочет брать text/xml? Но без него браузер не будет правильно обрабатывать.
Да вопрос задавался еще черт-те когда. А ответить соизволили как раз сегодня. Таки да, не поддерживает их робот Content-Type: text/xml.
Но зато они разрешили делать подмену заголовка специально для их робота - надо будет на стенку в рамочке повесить как официальное разрешение на клоакинг от яндекса:)
Но зато они разрешили делать подмену заголовка специально для их робота - надо будет на стенку в рамочке повесить как официальное разрешение на клоакинг от яндекса:)
Спасибо за статью, будем ждать продолжения :)
не в тему:
когда уже Хабр будет код подсвечивать и форматировать, а?
не в тему:
когда уже Хабр будет код подсвечивать и форматировать, а?
Надо подключить парсер 
Spearance
Spearance
Огромное спасибо за отличнейшую статью. Сам использую XSLT вот уже 3-й год весьма нравится. весьма быстро и удобно. Но мало еще народа переходит в сайтостроительстве на него, я надеюсь что после таких статей наших прибавится.
Как с помощью xslt вывести список в два столбца ?
например есть список:
<list>
<item>1</item>
<item>2</item>
<item>3</item>
<item>4</item>
<item>5</item>
<item>6</item>
</list>
Как его преобразовать в такое:
<table>
<tr>1<td></td><td>4</td></tr>
<tr>2<td></td><td>5</td></tr>
<tr>3<td></td><td>6</td></tr>
</table>
???
например есть список:
<list>
<item>1</item>
<item>2</item>
<item>3</item>
<item>4</item>
<item>5</item>
<item>6</item>
</list>
Как его преобразовать в такое:
<table>
<tr>1<td></td><td>4</td></tr>
<tr>2<td></td><td>5</td></tr>
<tr>3<td></td><td>6</td></tr>
</table>
???
использовать count(list/item) и в зависимости от этого строить нужное кол-во столбцов и строк в них.
Если вам нужны _визуальные_ столбцы, может, лучше использовать CSS и свойства float+width?
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/list">
<table>
<xsl:apply-templates select="item[count(preceding-sibling::item) <= count(following-sibling::item)]" mode="tr"/>
</table>
</xsl:template>
<xsl:template match="item" mode="tr">
<xsl:variable name="pos" select="ceiling(count(../item) div 2)"/>
<tr>
<xsl:apply-templates select="." mode="td"/>
<xsl:apply-templates select="following-sibling::item[$pos]" mode="td"/>
</tr>
</xsl:template>
<xsl:template match="item" mode="td">
<td><xsl:value-of select="."/></td>
</xsl:template>
</xsl:stylesheet>XML:
1
2
3
XSLT:
В браузере открывать XML, XSLT-шный файл обозвать transform.xsl и бросить тудаже где файл.xml
1
2
3
XSLT:
В браузере открывать XML, XSLT-шный файл обозвать transform.xsl и бросить тудаже где файл.xml
Когда код посылаете, нажимайте "предпросмотр", т.к. неясно как его хабр отформатирует.
Символы "<" нужно заменить на "<"
Сам код лучше обернуть в <code>...</code>.
Символы "<" нужно заменить на "<"
Сам код лучше обернуть в <code>...</code>.
ЕМАЕ! УЖАС КАКОЙ!!!! :D
Откуда такие грабли?
XML:
<?xml version="1.0" encoding="Windows-1251"?&rt;
<?xml-stylesheet type="text/xsl" href="transform.xsl"?&rt;
<list&rt;
<item&rt;1</item&rt;
<item&rt;2</item&rt;
<item&rt;3</item&rt;
</list&rt;
XSLT:
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"&rt;
<xsl:output method="html" encoding="windows-1251" doctype-system="http://www.w3.org/TR/html4/strict.dtd" doctype-public="-//W3C//DTD HTML 4.01//EN"/&rt;
<xsl:template match="/list"&rt;
<html&rt;
<body&rt;
<table&rt;
<xsl:for-each select="item[(position() - 1) mod 2=0]"&rt;
<tr&rt;
<td&rt;<xsl:value-of select="./text()" /&rt;</td&rt;
<td&rt;<xsl:value-of select="following-sibling::item/text()" /&rt;</td&rt;
</tr&rt;
</xsl:for-each&rt;
</table&rt;
</body&rt;
</html&rt;
</xsl:template&rt;
</xsl:stylesheet&rt;
Откуда такие грабли?
XML:
<?xml version="1.0" encoding="Windows-1251"?&rt;
<?xml-stylesheet type="text/xsl" href="transform.xsl"?&rt;
<list&rt;
<item&rt;1</item&rt;
<item&rt;2</item&rt;
<item&rt;3</item&rt;
</list&rt;
XSLT:
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"&rt;
<xsl:output method="html" encoding="windows-1251" doctype-system="http://www.w3.org/TR/html4/strict.dtd" doctype-public="-//W3C//DTD HTML 4.01//EN"/&rt;
<xsl:template match="/list"&rt;
<html&rt;
<body&rt;
<table&rt;
<xsl:for-each select="item[(position() - 1) mod 2=0]"&rt;
<tr&rt;
<td&rt;<xsl:value-of select="./text()" /&rt;</td&rt;
<td&rt;<xsl:value-of select="following-sibling::item/text()" /&rt;</td&rt;
</tr&rt;
</xsl:for-each&rt;
</table&rt;
</body&rt;
</html&rt;
</xsl:template&rt;
</xsl:stylesheet&rt;
Господи!!!!
Почему так криво то??? Какая нафиг подсветка синтаксиса, если оно простое то схавать не может?!!! Охренеть можно.... Раз в 5 минут и так криво!!! :D :D :D Я понимаю что надо предпросмотр юзать - но некогда мне - быстро написал пример и отправил.... Блин! Господа владельцы сайта, давайте я вам дам код для текстарии?? :D
Почему так криво то??? Какая нафиг подсветка синтаксиса, если оно простое то схавать не может?!!! Охренеть можно.... Раз в 5 минут и так криво!!! :D :D :D Я понимаю что надо предпросмотр юзать - но некогда мне - быстро написал пример и отправил.... Блин! Господа владельцы сайта, давайте я вам дам код для текстарии?? :D
Это решение задачи в другом направлении, где будет на выходе получаться
1 - 2
3 - 4
5 - 6
Требовалось же
1 - 4
2 - 5
3 - 6
что сложнее
1 - 2
3 - 4
5 - 6
Требовалось же
1 - 4
2 - 5
3 - 6
что сложнее
В коде много переменных, но за счет них он работает в IE.
А так, если использовать CGI-склеивание XML с XSL то код получиться короче
<xsl:variable name="totalItems"><xsl:value-of select="count(//list/item)"/></xsl:variable>
<xsl:variable name="totalItemsHalf"><xsl:value-of select="$totalItems div 2"/></xsl:variable>
<xsl:template match="//document">
<html>
<body>
<table border="1">
<xsl:apply-templates select="//list/item" mode="list"/>
</table>
</body>
</html>
</xsl:template>
<xsl:template match="item" mode="list">
<xsl:variable name="cur">
<xsl:value-of select="position()"/>
</xsl:variable>
<xsl:variable name="next">
<xsl:value-of select="$totalItemsHalf + $cur"/>
</xsl:variable>
<tr>
<xsl:choose>
<xsl:when test="position() > $totalItems div 2"></xsl:when>
<xsl:otherwise>
<td><xsl:value-of select="text()"/></td>
<td><xsl:value-of select="parent::*/item[position() = $next]/text()"/></td>
</xsl:otherwise>
</xsl:choose>
</tr>
</xsl:template>
А так, если использовать CGI-склеивание XML с XSL то код получиться короче
И смысл использования трансформации на клинете, если придется так извращаться? :)
Если трансформер не поддерживает стандарт, то не надо его использовать, это будет мучение одно.
Если трансформер не поддерживает стандарт, то не надо его использовать, это будет мучение одно.
Я привел пример для тех, у кого нет возможности по быстрому настроить CGI трансформацию. Этот пример можно просто загрузить в браузер и посмотреть.
Для рабочих проектов можно использовать все средства XSLT. В этом случае код уменьшается в разы и легче читается.
Я не говорю, что нужно использовать трансформацию на клиенте. Для этого пока нет достаточной поддержки со стороны браузеров.
Для рабочих проектов можно использовать все средства XSLT. В этом случае код уменьшается в разы и легче читается.
Я не говорю, что нужно использовать трансформацию на клиенте. Для этого пока нет достаточной поддержки со стороны браузеров.
подсказка:
match="item[position() div 2 = 1]"
match="item[position() div 2 = 1]"
о-о-о... что то это мне напоминает одно тестовое задание :)
я прав?
я прав?
XSLT на фронтенде пока зло. На РИТе помнится было смешно, когда про это рассказывал Кудинов (вроде).
Забили помидорами под корень.
Забили помидорами под корень.
А под фронтендом вы здесь подразумеваете клиент/браузер я так понимаю... чтобы почувствовать зло его ведь надо вкусить не так ли?.. вы его вкусили?.. надеюсь что нет. Мне, вот, повезло меньше, я вкусил, но, должен сказать, зло оказалось не таким уж противным на вкус))
Взять, к примеру, проблему индексации "сайта с XSLT на клиенте" поисковиками, проблема? согласен. А как насчет бэк-офисов, интранет-систем? если вы решаете задачу в этих рамках, то проблем с индексацией у вас уже нет, потому что она там не нужна. Видите, одним злом сразу стало меньше. Нужно просто поискать правильную сферу применения.
Что касается РИТа, то я на нем не был, но я смотрел запись этого доклада, мне он смешным не показался, мне он показался очень любопытным. Интересно, а как вы оцениваете ваши собственные доклады, уважаемый Flack?
Взять, к примеру, проблему индексации "сайта с XSLT на клиенте" поисковиками, проблема? согласен. А как насчет бэк-офисов, интранет-систем? если вы решаете задачу в этих рамках, то проблем с индексацией у вас уже нет, потому что она там не нужна. Видите, одним злом сразу стало меньше. Нужно просто поискать правильную сферу применения.
Что касается РИТа, то я на нем не был, но я смотрел запись этого доклада, мне он смешным не показался, мне он показался очень любопытным. Интересно, а как вы оцениваете ваши собственные доклады, уважаемый Flack?
Шо ж вы серьезный-то такой.
Нет, я неделаю интранет-проектов. Не интересно мне как-то. Так что для меня неиндексируемая технология не существует, уж извините :)
Я говорил не про доклад, а про обсуждение.
Нет, я неделаю интранет-проектов. Не интересно мне как-то. Так что для меня неиндексируемая технология не существует, уж извините :)
Я говорил не про доклад, а про обсуждение.
ну как можно обвинять в серьезности человека с такой аватаркой))
просто ваше утверждение звучит уж очень безапеляционно, мне захотелось немного его расшатать, и я не являюсь адвокатом Кудинова, но фраза показалась мне не очень дружелюбной)
P.S. Ты же сам докладчик, Лёха) прикинь, я напишу: было смешно, когда про это рассказывал Рыбаков (вроде)................ без обид)
просто ваше утверждение звучит уж очень безапеляционно, мне захотелось немного его расшатать, и я не являюсь адвокатом Кудинова, но фраза показалась мне не очень дружелюбной)
P.S. Ты же сам докладчик, Лёха) прикинь, я напишу: было смешно, когда про это рассказывал Рыбаков (вроде)................ без обид)
я рассказывал, и сам же сказал что делать этого не стоит (если ты не делаешь админку под себя или интранет) и объяснил почему.
а вопрос этот обсуждается и сейчас, а толковой информации как небыло так и нет.
а вопрос этот обсуждается и сейчас, а толковой информации как небыло так и нет.
и не на РИТе, а ClientSide
Хех… хабр весь исходный код поел((
Fade, не дадите ссылку на эту статью на другом сайте, где такой беды не приключилось?)
Fade, не дадите ссылку на эту статью на другом сайте, где такой беды не приключилось?)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Практический XSLT. Использование в качестве шаблонизатора