Comments 52
по долгу службы пришлось разбираться с xpath/xquery
можете посоветовать материалы для чтения в открытом доступе? а то я больше пары простеньких туториалов не нашел
можете посоветовать материалы для чтения в открытом доступе? а то я больше пары простеньких туториалов не нашел
Кроме документации могу посоветовать XSLT в примерах.
не, xslt не интересует. интересует xquery
UFO just landed and posted this here
на самом деле очень хороший сайт, есть почти всё. Разобраться во всём можно
Странно — почему заминусовали вас? www.w3schools.com/XPath/xpath_syntax.asp — например вполне себе минимум нормальный по Xpath селекторам.
UFO just landed and posted this here
Могу посоветовать старый добрый www.zvon.org
Есть и статьи и туториалы и даже утилиты-тесты, чтоб можно было поиграться с xpath и визуально видеть какие узлы попали в выборку. Главы посвящённые xpath есть так же и в туториалах по xslt (кстати русская версия на www.raleigh.ru, упомянутая razetdinov как раз и есть перевод с этого сайта).
Есть и статьи и туториалы и даже утилиты-тесты, чтоб можно было поиграться с xpath и визуально видеть какие узлы попали в выборку. Главы посвящённые xpath есть так же и в туториалах по xslt (кстати русская версия на www.raleigh.ru, упомянутая razetdinov как раз и есть перевод с этого сайта).
Я бы ещё добавил, что особенности сравнения в XPath позволяют делать некоторые вещи намого проще, чем в других языках.
Например join: person[@name = $vip/person/@name] позволяет найти людей, у которых имя встречается в списке VIP (а не равно всему списку сразу, как кажется).
Например join: person[@name = $vip/person/@name] позволяет найти людей, у которых имя встречается в списке VIP (а не равно всему списку сразу, как кажется).
UFO just landed and posted this here
Есть много задач, которые достаточно быстро и красиво. Особенно когда много работы с XML.
На мой взгляд, язык хорошо справляется со своей задачей: трансформацией XML-документов.
Имеет место многословность синтаксиса, но при соблюдении определённых правил почти не мешает.
Имеет место многословность синтаксиса, но при соблюдении определённых правил почти не мешает.
Да. Большое удовольствие.
Плюс я использую XSLT как шаблонизатор во всех своих проектах.
Плюс я использую XSLT как шаблонизатор во всех своих проектах.
XSLT — лучшее, что можно придумать для presentation layer
Дополнение по generate-id($foo) = generate-id($bar): если под сравнение попадёт множество $foo, где первым узлом будет $bar — выражение вернёт true.
То же самое будет если обе переменные будут множествами и первыми узлами в обоих будет один и тот же узел.
То же самое будет если обе переменные будут множествами и первыми узлами в обоих будет один и тот же узел.
Жаль, что XSLT среди Российских веб-разработчиков, так не популярен. Гораздо проще забыв про валидность html и полное отделение логики от представления делать сайты на псевдо-шаблонизаторах.
Освоил создание сайтов на XML+XSLT в 2002г, с тех пор не признаю других связок, но студии с которыми приходится работать, считают это слишком сложной и трудоемкой технологией, и что сайты на ней нельзя делать. Если кто поскажет правильный довод, чтобы переубедить, буду благодарен.
Свои личные проекты создаю только на XSLT с трансформацией на стороне сервера.
Освоил создание сайтов на XML+XSLT в 2002г, с тех пор не признаю других связок, но студии с которыми приходится работать, считают это слишком сложной и трудоемкой технологией, и что сайты на ней нельзя делать. Если кто поскажет правильный довод, чтобы переубедить, буду благодарен.
Свои личные проекты создаю только на XSLT с трансформацией на стороне сервера.
> Если кто поскажет правильный довод, чтобы переубедить, буду благодарен.
«Так делает Яндекс».
Беда у XSLT одна — скорость.
И что-то поделать с этой бедой затруднительно.
Радости XPath и DOM дорого стоят.
«Так делает Яндекс».
Беда у XSLT одна — скорость.
И что-то поделать с этой бедой затруднительно.
Радости XPath и DOM дорого стоят.
Вы противоречите сами себе — если бы скорость трансформации была насколько узким местом, то Яндекс вряд ли бы ее использовал для подавляющего большинства своих сервисов.
Я нигде не говорил, что скорость «настолько узкое место, что XSLT нельзя использовать».
Практически всегда скоростью можно пожертвовать в угоду достоинств.
Практически всегда скоростью можно пожертвовать в угоду достоинств.
Ай, отправил не дописав.
Однако, XSLT всегда будет медленнее любого простого шаблонизатора.
Однако, XSLT всегда будет медленнее любого простого шаблонизатора.
Я вам следующее скажу… Для XSL трансформаций, так же как и для работы с самим деревом используются, в основном, библиотеки написанные преимущественно на Си. А это означает что скорость отработки «pure» скриптового шаблонизатора (как вы сказали «простого») будет, как минимум, сопоставима с XSLT. Однако, подход XML + XSLT обладает такими вкусностями, что никаким иным шаблонизаторам и не снилось.
Они не могут быть сопоставимы, как раз из-за «вкусностей».
Накладные расходы сильно больше. В том числе, по памяти.
Работа с деревом тяжёлая.
Много тяжелей, чем разобрать строку шаблона по REGEX'у и дёрнуть вызовы инструкций.
Лучше, конечно, иметь какой-нибудь пример и посмотреть на цифры, но у меня такого примера, к сожалению, нет.
Накладные расходы сильно больше. В том числе, по памяти.
Работа с деревом тяжёлая.
Много тяжелей, чем разобрать строку шаблона по REGEX'у и дёрнуть вызовы инструкций.
Лучше, конечно, иметь какой-нибудь пример и посмотреть на цифры, но у меня такого примера, к сожалению, нет.
Успешно использую XSLT в проекте с посещаемостью ~7.000.000 хитов в день. Все работает на одном выделенном сервере с парой ксеонов. Так что проблемы скорости XSLT во многом надуманы
Рибяты, я не говорю, что XSLT — жуткий тормоз.
Несколько лет делал сайты только с его применением, скорость достаточна.
Но, в сравнении с простыми шаблонизаторами, где примитивные возможности и такой же синтаксис, XSLT, понятное дело, проигрывает.
Бывает (бывает), что на серьёзных шаблонах и объёмных страницах время трансформации — 3/4 всего времени генерации. Что, конечно, существенно.
Несколько лет делал сайты только с его применением, скорость достаточна.
Но, в сравнении с простыми шаблонизаторами, где примитивные возможности и такой же синтаксис, XSLT, понятное дело, проигрывает.
Бывает (бывает), что на серьёзных шаблонах и объёмных страницах время трансформации — 3/4 всего времени генерации. Что, конечно, существенно.
>>Но, в сравнении с простыми шаблонизаторами, где примитивные возможности и такой же синтаксис, XSLT, понятное дело, проигрывает.
у XSLT примитивные возможноcти?
Я не встречал ниодного шаблонизатора круче XSLT :) особенно если есть внутренние протоколы в системе.
у XSLT примитивные возможноcти?
Я не встречал ниодного шаблонизатора круче XSLT :) особенно если есть внутренние протоколы в системе.
Запятую после «синтаксис» видите?..
Понимаете, что там заканчивается часть, относящаяся к «простым шаблонизаторам»?
Понимаете, что там заканчивается часть, относящаяся к «простым шаблонизаторам»?
А в чём бонус по сравнению с шаблонизатором?
Мне кажется с XSLT кода гораздо больше, HTML сложнее предсказать по коду, etc.
Мне кажется с XSLT кода гораздо больше, HTML сложнее предсказать по коду, etc.
Может быть и неудачный пример но:
Допустим есть большой проект, программная часть отдает только XML данные, есть верстальщик который знает только XSLT,
перед ним лежит распечатка развернутого дерева данных всего проекта, всех модулей, всех блоков.
Ему все видно и понятно.
А допустим, если используются шаблоны аля smarty, верстальщику придется спрашивать прогера как называются те или иные элементы и как к ним добраться, думаю с другими шаблонами-скриптами будет тоже самое.
Про объемность кода, забываешь когда понимаешь удобство Xpath. Да и просто уметь быстро набирать код.
Допустим есть большой проект, программная часть отдает только XML данные, есть верстальщик который знает только XSLT,
перед ним лежит распечатка развернутого дерева данных всего проекта, всех модулей, всех блоков.
Ему все видно и понятно.
А допустим, если используются шаблоны аля smarty, верстальщику придется спрашивать прогера как называются те или иные элементы и как к ним добраться, думаю с другими шаблонами-скриптами будет тоже самое.
Про объемность кода, забываешь когда понимаешь удобство Xpath. Да и просто уметь быстро набирать код.
Верстальшик который знает именно XSLT это очень особая ситуация.
У нас например в 90% случаев как раз программисты знают вёрстку.
Потому что это несложно и полезно знать.
Программирование — искусство читаемости, а не скорости набора.
У нас например в 90% случаев как раз программисты знают вёрстку.
Потому что это несложно и полезно знать.
Да и просто уметь быстро набирать код.
Программирование — искусство читаемости, а не скорости набора.
We Are Typists First, Programmers Second
Согласен с Джефом: скорость набора имеет значение.
Согласен с Джефом: скорость набора имеет значение.
>программисты знают вёрстку… потому что это несложно и полезно знать.
Баги верстки, внесенные подобными знатоками самые тяжелые для выявления.
Впрочем, Smarty-верстальщик «разбирающийся» в программировании тоже способен на многое.
Да и вообще XSLT тем и хорош, что разрешает 99% конфликтов программист-верстальщик.
Баги верстки, внесенные подобными знатоками самые тяжелые для выявления.
Впрочем, Smarty-верстальщик «разбирающийся» в программировании тоже способен на многое.
Да и вообще XSLT тем и хорош, что разрешает 99% конфликтов программист-верстальщик.
> Баги верстки, внесенные подобными знатоками самые тяжелые для выявления.
Пример?
Пример?
Последний в моей практике — внесение невалидного кода приводило к нарушениям работы в JS.
Да в общем какая разница? Каждый должен заниматься своим делом.
Да в общем какая разница? Каждый должен заниматься своим делом.
Это удивительно, но мои программисты и правда знают верстку, и даже знают JS (до уровня prototypes/closures).
Но исходный вопрос был даже не про это — верстальщик который знает XSLT, но не способен разобраться с другими языками темплейтов — немного странно звучит для меня.
A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.
Но исходный вопрос был даже не про это — верстальщик который знает XSLT, но не способен разобраться с другими языками темплейтов — немного странно звучит для меня.
>мои программисты и правда знают верстку
Главное чтобы не верстали :)
«Беда, коль пироги начнет печи сапожник, а сапоги тачать пирожник.» (с) И.А. Крылов
>верстальщик который знает XSLT, но не способен
Могут быть проблемы не когнитивного плана, а физиологического. Например может мешать рвотный рефлекс. Мне например очень трудно подавить его при виде Smarty, хотя он не самый отвратительный.
Главное чтобы не верстали :)
«Беда, коль пироги начнет печи сапожник, а сапоги тачать пирожник.» (с) И.А. Крылов
>верстальщик который знает XSLT, но не способен
Могут быть проблемы не когнитивного плана, а физиологического. Например может мешать рвотный рефлекс. Мне например очень трудно подавить его при виде Smarty, хотя он не самый отвратительный.
Jquery — например падает если обращается к таблицы у которой есть namespace :)
Sign up to leave a comment.
Проверка равенства, неравенства, идентичности узлов в XPath