Стоит ли использовать XSLT?[закрыто]
https://stackoverflow.com/questions/78716
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Некоторое время назад я начал проект, в котором разработал XML-схему в стиле HTML, чтобы авторы могли писать свой контент (материалы учебных курсов) в упрощенном формате, который затем преобразовывался в HTML с помощью XSLT.Я играл (боролся) с ним некоторое время и довел его до самого базового уровня, но затем меня слишком раздражали ограничения, с которыми я столкнулся (которые вполне могли быть ограничениями моих знаний), и когда я прочитал блог, предлагающий отказаться от XSLT и просто напишите свой собственный синтаксический анализатор XML в любой другой язык на выбранном вами языке. Я с радостью взялся за это, и это сработало блестяще.
Я работаю над этим по сей день(Я вообще-то должен сейчас над этим работать, а не играть в SO.), и я вижу все больше и больше вещей, которые заставляют меня думать, что решение отказаться от XSLT было правильным.
Я знаю, что XSLT имеет свое место, поскольку это общепринятый стандарт, и что если каждый будет писать свои собственные интерпретаторы, 90% из них в конечном итоге окажутся на TheDailyWTF.Но учитывая, что это язык функционального стиля вместо процедурного стиля, знакомого большинству программистов, для тех, кто приступает к такому проекту, как мой, вы бы порекомендовали им пойти по тому же пути, что и я, или придерживаться его с помощью XSLT??
Решение
Преимущества XSLT:
- Зависит от домена для XML, поэтому, например, нет необходимости заключать в кавычки буквенный XML в выходных данных.
- Поддерживает XPath/XQuery, который может быть хорошим способом запроса DOM, точно так же, как регулярные выражения могут быть хорошим способом запроса строк.
- Функциональный язык.
Недостатки XSLT:
- Может быть неприлично многословным — вам не нужно цитировать буквальный XML, что фактически означает, что вам нужно цитировать код.И не в красивом смысле.Но опять же, это не намного хуже обычного SSI.
- Не делает некоторых вещей, которые большинство программистов считают само собой разумеющимися.Например, манипулирование строками может оказаться рутинной работой.Это может привести к «неудачным моментам», когда новички проектируют код, а затем лихорадочно ищут в Интернете подсказки о том, как реализовать функции, которые, как они предполагали, просто существуют, и не дают себе времени на написание.
- Функциональный язык.
Кстати, один из способов получить процедурное поведение — объединить несколько преобразований в цепочку.После каждого шага у вас есть совершенно новый DOM для работы, который отражает изменения, произошедшие на этом этапе.Некоторые процессоры XSL имеют расширения, позволяющие эффективно делать это за одно преобразование, но я забываю подробности.
Итак, если ваш код в основном состоит из вывода и не содержит большого количества логики, XSLT может стать очень удобным способом его выражения.Если логики много, но в основном это формы, встроенные в XSLT (выберите все элементы, которые выглядят как бла, и для каждого выведите бла), скорее всего, это будет вполне дружественная среда.Если вам нравится всегда думать в духе XML, попробуйте XSLT 2.
В противном случае я бы сказал, что если ваш любимый язык программирования имеет хорошую реализацию DOM, поддерживающую XPath и позволяющую вам создавать документы полезным способом, то использование XSLT дает мало преимуществ.Привязки к libxml2 и gdome2 должны работать хорошо, и нет ничего постыдного в том, чтобы придерживаться языков общего назначения, которые вы хорошо знаете.
Самодельные анализаторы XML обычно либо неполны (в этом случае вы когда-нибудь застрянете), либо ненамного меньше того, что вы могли бы получить с полки (в этом случае вы, вероятно, зря тратите свое время), и дают у вас есть множество возможностей создать серьезные проблемы безопасности, связанные с вредоносным вводом.Не пишите ничего, если точно не знаете, что вы от этого получите.Это не означает, что вы не можете написать анализатор для чего-то более простого, чем XML, в качестве входного формата, если вам не нужно все, что предлагает XML.
Другие советы
Столько негатива!
Я использую XSLT уже несколько лет, и мне он искренне нравится.Главное, что вы должны осознать, это то, что это не язык программирования, это язык шаблонов (и в этом отношении я считаю его неописуемо превосходящим asp.net/spit).
Сегодня XML является фактическим форматом данных веб-разработки, будь то файлы конфигурации, необработанные данные или представление в памяти.XSLT и XPath дают вам чрезвычайно мощный и очень эффективный способ преобразования этих данных в любой выходной формат, который вам нравится, мгновенно предоставляя вам MVC-аспект отделения представления от данных.
Тогда есть полезные способности:вымывание пространств имен, распознавание несопоставимых определений схемы, объединение документов.
Это должен лучше иметь дело с XSLT, чем разрабатывать собственные методы.По крайней мере, XSLT является стандартом, и вы можете нанять его, и если это действительно проблема для вашей команды, сама природа позволит вам заставить большую часть вашей команды работать только с XML.
Реальный пример использования:Я только что написал приложение, которое обрабатывает XML-документы в памяти всей системы и преобразует их в JSON, HTML или XML по запросу конечного пользователя.У меня был довольно случайный запрос на предоставление данных в формате Excel.Бывший коллега сделал нечто подобное программно, но для этого требовался модуль из нескольких файлов классов и чтобы на сервере был установлен MS Office!Оказывается, в Excel есть XSD:новая функциональность с минимальным воздействием на базовый код за 3 часа.
Лично я считаю, что это одна из самых чистых вещей, с которыми я когда-либо сталкивался в своей карьере, и считаю, что все очевидные проблемы (отладка, манипуляции со строками, структуры программирования) сводятся к неправильному пониманию этого инструмента.
Очевидно, я твердо верю, что оно «стоит того».
Я должен признать здесь предвзятость, потому что я зарабатываю на жизнь преподаванием XSLT.Но, возможно, стоит скрыть те области, в которых, как я вижу, работают мои ученики.Обычно они делятся на три группы:издательское дело, банковское дело и Интернет.
Многие из ответов на данный момент можно резюмировать следующим образом: «Он бесполезен для создания веб-сайтов» или «Это не что иное, как язык X».Многие технические специалисты делают свою карьеру, не знакомясь с функциональными/декларативными языками.Когда я преподаю, у опытных людей, использующих Java/VB/C/и т. д., возникают проблемы с языком (переменные - это переменные в смысле алгебры, а не, например, процедурного программирования).Здесь отвечают многие люди - я никогда не разбирался в Java, но из-за этого я не собираюсь критиковать этот язык.
Во многих случаях это неподходящий инструмент для создания веб-сайтов — лучше использовать язык программирования общего назначения.Мне часто приходится брать очень большие XML-документы и размещать их в Интернете;XSLT делает это тривиальным.Студенты, которых я вижу в этом пространстве, обычно обрабатывают наборы данных и представляют их в Интернете.XSLT, конечно, не единственный применимый инструмент в этой области.Однако многие из них используют для этого DOM, а XSLT, безусловно, менее болезненный метод.
Студенты банковского дела, которых я вижу, обычно используют блок DataPower.Это устройство XML, которое используется для взаимодействия между службами, «говорящими» на разных диалектах XML.Преобразование одного языка XML в другой в XSLT практически тривиально, и число студентов, посещающих мои курсы по этому вопросу, увеличивается.
Последняя группа студентов, которую я вижу, имеет издательский опыт (как и я).Эти люди, как правило, имеют огромные документы в формате XML (поверьте мне, издательская индустрия все больше увлекается XML - технические публикации существуют уже много лет, а отраслевые публикации - сейчас).Эти документы необходимо обработать (здесь на ум приходит DocBook to ePub).
Кто-то выше заметил, что сценарии обычно имеют длину менее 60 строк или становятся громоздкими.Если он действительно станет громоздким, скорее всего, программист на самом деле не догадался об этом — XSLT сильно отличается от многих других языков.Если вы не поймете образ мышления, это не сработает.
Это определенно не умирающий язык (об этом мне говорит объем работы, которую я получаю).На данный момент ситуация немного «застряла», пока Microsoft не завершит (очень позднюю) реализацию XSLT 2.Но он все еще существует и, с моей точки зрения, похоже, набирает силу.
Мы широко используем XSLT для таких вещей, как документация и обеспечение удобства обслуживания некоторых сложных настроек конфигурации.
Для документации мы часто используем DocBook — формат на основе XML.Это позволяет нам хранить документацию со всем исходным кодом и управлять ею, поскольку файлы представляют собой обычный текст.С помощью XSLT мы можем легко создавать собственные форматы документации, что позволяет нам автоматически генерировать контент общим способом и делать его более читабельным.Например, когда мы публикуем примечания к выпуску, мы можем создать XML, который выглядит примерно так:
<ReleaseNotes>
<FixedBugs>
<Bug id="123" component="Admin">Error when clicking the Foo button</Bug>
<Bug id="125" component="Core">Crash at startup when configuration is missing</Bug>
<Bug id="127" component="Admin">Error when clicking the Bar button</Bug>
</FixedBugs>
</ReleaseNotes>
А затем, используя XSLT (который преобразует приведенное выше в DocBook), мы получаем хорошие примечания к выпуску (обычно в формате PDF или HTML), где идентификаторы ошибок автоматически связываются с нашим трекером ошибок, ошибки группируются по компонентам, и формат всего идеально согласован. .Приведенный выше XML-код можно сгенерировать автоматически, запросив в нашем трекере ошибок то, что изменилось между версиями.
Еще одно место, где мы обнаружили полезность XSLT, — это наш основной продукт.Иногда при взаимодействии со сторонними системами нам необходимо каким-то образом обработать данные сложной HTML-страницы.Анализ HTML уродлив, поэтому мы передаем данные через что-то вроде ТегСуп (который генерирует правильные XML-события SAX, по сути позволяя нам работать с HTML, как если бы он был правильно написанным XML), а затем мы можем запустить против него некоторый XSLT, чтобы превратить данные в «известный стабильный» формат, с которым мы действительно можем работать. .Выделение этого преобразования в файл XSLT означает, что если и когда формат HTML изменится, само приложение не нужно будет обновлять, вместо этого конечный пользователь может просто отредактировать файл XSLT самостоятельно или мы можем отправить его по электронной почте. им обновленный файл XSLT без необходимости обновления всей системы.
Я бы сказал, что для веб-проектов сегодня существуют лучшие способы обработки стороны представления, чем XSLT, но как технология XSLT определенно найдет применение.Это не самый простой в использовании язык в мире, но он определенно не умер и, с моей точки зрения, еще имеет множество полезных применений.
XSLT является примером декларативное программирование язык.
Другие примеры декларативных языков программирования включают регулярные выражения, Пролог и SQL.Все они очень выразительны и компактны, обычно очень хорошо спроектированы и мощны для решения той задачи, для которой они предназначены.
Однако разработчики программного обеспечения обычно ненавидят такие языки, поскольку они настолько отличаются от более распространенных объектно-ориентированных или процедурных языков, что их трудно изучать и отлаживать.Их компактность обычно позволяет легко случайно нанести большой ущерб.
Таким образом, хотя XSLT является эффективным механизмом объединения данных в представление, он терпит неудачу с точки зрения простоты использования.Я считаю, что именно поэтому это не прижилось.
Я помню всю шумиху вокруг XSLT, когда стандарт был только что выпущен.Все волнение вокруг возможности создать целый HTML-интерфейс с помощью «простого» преобразования.
Давайте посмотрим правде в глаза: его сложно использовать, его практически невозможно отлаживать, и зачастую он невыносимо медленный.Конечный результат почти всегда необычен и далёк от идеала.
Я скорее отгрызу себе ногу, чем воспользуюсь XSLT, хотя есть способы получше.Тем не менее, у него есть свои места, он хорош для простых задач преобразования.
Я широко использовал XSLT (а также XQuery) для разных целей: для генерации кода C++ в процессе сборки, для создания документации из комментариев к документации, а также в приложении, которому приходилось много работать с XML в целом и XHTML в частности. .Генератор кода, в частности, содержал более 10 000 строк кода XSLT 2.0, разбросанных по примерно дюжине отдельных файлов (он делал много вещей - заголовки для клиентов, удаленные прокси/заглушки, оболочки COM, оболочки .NET, ORM - если назвать немного).Я унаследовал его от другого парня, который плохо понимал язык, и поэтому старые фрагменты были совершенно беспорядочными.Однако новые материалы, которые мы написали, в основном оставались вменяемыми и читабельными, и я не припоминаю каких-либо особых проблем с этим.Конечно, это было не сложнее, чем сделать это для C++.
Говоря о версиях, работа с XSLT 2.0 определенно помогает вам оставаться в здравом уме, но версия 1.0 по-прежнему подходит для более простых преобразований.В своей нише это чрезвычайно удобный инструмент, и производительность, которую вы получаете от некоторых функций, специфичных для предметной области (самое главное, динамическая отправка через сопоставление шаблонов), трудно сравниться с ней.Несмотря на кажущуюся многословность синтаксиса XSLT, основанного на XML, то же самое в LINQ to XML (даже в VB с литералами XML) обычно было в несколько раз длиннее.Однако довольно часто он подвергается незаслуженной критике, в первую очередь из-за ненужного использования XML.
Подвести итог:Это невероятно полезный инструмент, который можно иметь в своем наборе инструментов, но он очень специализированный, поэтому он хорош, если вы используете его правильно и по назначению.Мне бы очень хотелось, чтобы существовала правильная, встроенная реализация XSLT 2.0 для .NET.
Я использую XSLT (из-за отсутствия лучшей альтернативы), но не для представления, а только для преобразования:
Я пишу короткие преобразования XSLT для массового редактирования наших файлов maven pom.xml.
Я написал конвейер преобразований для генерации XML-схем из XMI (UML-диаграммы).Какое-то время это работало, но в конце концов стало слишком сложным, и нам пришлось вынести его за сарай.
Я использовал преобразования для рефакторинга XML-схем.
Я обошел некоторые ограничения XSLT, используя его для создания XSLT для выполнения реальной работы.(Вы когда-нибудь пытались написать XSLT, который выдает выходные данные, используя пространства имен, неизвестные до времени выполнения?)
Я продолжаю возвращаться к нему, потому что он лучше справляется с обработкой XML, чем другие подходы, которые я пробовал, которые кажутся ненужными потерями или просто неправильно понимают XML.XSLT неприятен, но я считаю, что использование Кислород делает это терпимым.
Тем не менее, я исследую использование Кложур (lisp) для выполнения преобразований XML, но я еще не продвинулся достаточно далеко, чтобы понять, принесет ли мне этот подход пользу.
Лично я использовал XSLT в совершенно другом контексте.Компьютерная игра, над которой я тогда работал, использовала множество страниц пользовательского интерфейса, определенных с использованием XML.Во время крупного рефакторинга вскоре после выпуска мы хотели изменить структуру этих XML-документов.Мы сделали формат ввода игры более удобным и структурированным с учетом схемы.
XSLT показался идеальным выбором для перевода из старого формата в новый формат.В течение двух недель я успешно конвертировал сотни наших страниц из старого в новое.Я также смог использовать его для извлечения большого количества информации о макете наших страниц пользовательского интерфейса.Я создал списки того, какие компоненты были встроены в какие относительно легко, а затем использовал XSLT для записи в определения нашей схемы.
Кроме того, учитывая опыт работы с C++, освоить этот язык было очень весело и интересно.
Я думаю, что как инструмент для перевода XML из одного формата в другой он просто великолепен.Однако это не единственный способ определить алгоритм, который принимает XML в качестве входных и выходных данных. Что-нибудь.Если ваш алгоритм достаточно сложен, тот факт, что входные данные представляют собой XML, становится нерелевантным для вашего выбора инструмента - т.е. используйте свой собственный на C++/Python/что-то еще.
Что касается вашего примера, я думаю, что лучшей идеей было бы создать собственное преобразование XML->XML, соответствующее вашей бизнес-логике.Затем напишите XSLT-переводчик, который просто разбирается в форматировании и не делает ничего умного.Это может быть хорошей золотой серединой, но это полностью зависит от того, что вы делаете.Наличие транслятора XSLT на выходе упрощает создание альтернативных выходных форматов — для печати, для мобильных устройств и т. д.
Да, я часто им пользуюсь.Используя разные файлы xslt, я могу использовать один и тот же источник XML для создания нескольких многоязычных (X)HTML-файлов (представляющих одни и те же данные разными способами), канала RSS, канала Atom, файла дескриптора RDF и фрагмента карты сайта. .
Это не панацея.Есть вещи, которые он делает хорошо, и вещи, которые он делает не очень хорошо, и, как и во всех других аспектах программирования, все дело в использовании правильного инструмента для правильной работы.Это инструмент, который стоит иметь в своем наборе инструментов, но использовать его следует только тогда, когда это уместно.
Я определенно рекомендую это выдержать.Особенно, если вы используете Visual Studio со встроенными инструментами редактирования, просмотра и отладки для XSLT.
Да, это боль во время обучения, но большая часть боли связана с знакомством.Боль уменьшается по мере того, как вы изучаете язык.
На W3schools есть две статьи, которые имеют особую ценность:http://www.w3schools.com/xpath/xpath_functions.asp http://www.w3schools.com/xsl/xsl_functions.asp
Я обнаружил, что с XSLT довольно сложно работать.
У меня был опыт работы с системой, несколько похожей на ту, которую вы описываете.Моя компания отметила, что данные, которые мы возвращали из «среднего уровня», были в формате XML, и что страницы должны были отображаться в HTML, который с таким же успехом мог бы быть XHTML, плюс они слышали, что XSL является стандартом для преобразования между XML. форматы.Поэтому «архитекторы» (под которыми я подразумеваю людей, которые глубоко задумываются о дизайне, но, очевидно, никогда не пишут код) решили, что наш передний уровень будет реализован путем написания сценариев XSLT, которые преобразуют данные в XHTML для отображения.
Выбор оказался катастрофическим.Оказывается, XSLT писать очень сложно.Поэтому все наши страницы было сложно писать и поддерживать.Нам было бы гораздо лучше использовать JSP (это было в Java) или какой-либо аналогичный подход, который использовал бы один вид разметки (угловые скобки) для формата вывода (HTML) и другой вид разметки (например, <%... %>) для метаданных.Самое запутанное в XSLT то, что он написан на XML и преобразуется из XML в XML...довольно сложно удержать в уме все три разных XML-документа.
У вас немного другая ситуация:вместо того, чтобы создавать каждую страницу в XSLT, как это делал я, вам нужно написать всего лишь ОДИН бит кода в XSLT (код для преобразования из шаблонов для отображения).Но похоже, что вы столкнулись с теми же трудностями, что и я.Я бы сказал, что попытка интерпретировать простой DSL на основе XML (предметно-ориентированный язык), как вы это делаете, НЕ является одной из сильных сторон XSLT.(Хотя он МОЖЕТ выполнить эту работу...в конце концов, это Тьюринг-полный!)
Однако, если бы у вас было проще:у вас есть данные в одном формате XML и вы хотите внести в них простые изменения - не полный DSL с описанием страницы, а несколько простых и понятных модификаций, тогда XSLT - отличный инструмент для этой цели.Его декларативный (не процедурный) характер на самом деле является преимуществом для этой цели.
-- Майкл Чермсайд
С XSLT сложно работать, но как только вы освоите его, вы получите очень полное понимание DOM и схемы.Если вы также используете XPath, то вы на пути к изучению функционального программирования, и это откроет вам новые методы и способы решения проблем.В некоторых случаях последовательное преобразование является более эффективным, чем процедурные решения.
Я широко использую XSLT для создания пользовательского интерфейса в стиле MVC.Модель «сериализуется» в xml (не через сериализацию xml), а затем преобразуется в html через xslt.Преимущество перед ASP.NET заключается в естественной интеграции с XPath и более строгих требованиях к правильности формата (в xslt гораздо проще рассуждать о структуре документа, чем в большинстве других языков).
К сожалению, язык содержит несколько ограничений (например, возможность преобразовывать выходные данные другого преобразования), из-за чего иногда с ним становится неприятно работать.
Тем не менее, легко достижимое, строго принудительное разделение задач, которое она обеспечивает, - это не то, что я вижу сейчас в других технологиях, поэтому для преобразований документов я все равно рекомендую это.
Где-то в 2004 году я использовал XML, XSD и XSLT в проекте интеграции очень разных систем баз данных.Мне пришлось изучать XSD и XSLT с нуля, но это было несложно.Самое замечательное в этих инструментах было то, что они позволяли мне писать независимый от данных код C++, полагаясь на XSD и XSLT для проверки и последующего преобразования XML-документов.Измените формат данных, измените документы XSD и XSLT, а не код C++, в котором используются библиотеки Xerces.
Для интереса:основной XSD составлял 150 КБ, а средний размер XSLT был <5 КБ IIRC.
Еще одним большим преимуществом является то, что XSD является документом спецификации, на котором основан XSLT.Эти двое работают в гармонии.В наши дни спецификации редко встречаются в разработке программного обеспечения.
Хотя у меня не было особых проблем с изучением декларативной природы XSD и XSLT, я обнаружил, что другим программистам C/C++ было очень трудно приспособиться к декларативному подходу.Когда они увидели, что это все, ах, процедурно, они пробормотали, теперь, когда я понимаю!И они приступили (каламбур?) к написанию процедурного XSLT!Дело в том, что вам нужно изучить XPath и понимать оси XML.Напоминает мне старых программистов на языке C, которые приспосабливались к использованию объектно-ориентированного подхода при написании C++.
Я использовал эти инструменты, поскольку они позволили мне написать небольшую базу кода C++, которая была изолирована от всех изменений структуры данных, кроме самых фундаментальных, а последние представляли собой изменения структуры БД.Несмотря на то, что я предпочитаю C++ любому другому языку, я буду использовать то, что считаю полезным для обеспечения долгосрочной жизнеспособности программного проекта.
Раньше я думал, что XSLT — отличная идея.я серьезно является отличная идея.
Где это терпит неудачу, так это исполнение.
Проблема, которую я обнаружил со временем, заключалась в том, что языки программирования на XML — это просто плохая идея.Это делает все непроницаемым.В частности, я считаю, что XSLT очень сложно выучить, написать код и понять.XML поверх функциональных аспектов просто делает все это слишком запутанным.Я пытался выучить это около 5 раз за свою карьеру, но ничего не получилось.
Хорошо, вы могли бы «инструментировать» его — я думаю, что отчасти это было целью его дизайна — но это второй недостаток:все инструменты XSLT, имеющиеся на рынке, проще говоря...дерьмо!
А XSLT-спецификация определяет XSLT как «язык преобразования XML-документов в другие XML-документы».Если вы пытаетесь сделать что-то, кроме самой базовой обработки данных в XSLT, возможно, есть лучшие решения.
Также стоит отметить, что возможности обработки данных XSLT можно расширить в .NET с помощью пользовательских функций расширения:
Я поддерживаю онлайн-систему документации для своей компании.Авторы создают документацию на SGML (языке, похожем на XML).Затем SGML объединяется с XSLT и преобразуется в HTML.
Это позволяет нам легко вносить изменения в макет документации без какого-либо кодирования.Это просто вопрос изменения XSLT.
Это хорошо работает для нас.В нашем случае это документ только для чтения.Пользователь не взаимодействует с документацией.
Кроме того, используя XSLT, вы приближаетесь к проблемной области (HTML).Я всегда считаю это хорошей идеей.
Наконец, если ваша текущая система РАБОТАЕТ, оставьте ее в покое.Я бы никогда не предложил уничтожить существующий код.Если бы я начинал с нуля, я бы использовал XSLT, но в вашем случае я бы использовал то, что есть у вас.
Все сводится к тому, для чего вам это нужно.Его главная сила — простота сопровождения преобразования, и написание собственного синтаксического анализатора обычно стирает это.С учетом вышесказанного, иногда система небольшая и простая и действительно не нуждается в «причудливом» решении.Если ваш конструктор на основе кода можно заменить без необходимости изменения другого кода, в этом нет ничего страшного.
Что касается уродства XSL, да, это уродство.Да, к этому нужно привыкнуть.Но как только вы освоите это (это, по моему мнению, не займет много времени), все пойдет гладко.По моему опыту, скомпилированные преобразования выполняются довольно быстро, и их, безусловно, можно отладить.
Я по-прежнему верю, что XSLT может быть полезен, но это уродливый язык, который может привести к ужасной нечитаемой и неподдерживаемой путанице.Частично потому, что XML недостаточно удобочитаем для человека, чтобы составить «язык», а частично потому, что XSLT застрял где-то между декларативностью и процедурностью.Тем не менее, и я думаю, что сравнение можно провести с регулярными выражениями, оно полезно, когда речь идет о простых, четко определенных проблемах.
Использование альтернативного подхода и анализ XML в коде может быть столь же неприятным, и вам действительно хочется использовать какую-то технологию маршалинга/связывания XML (например, JiBX в Java), которая преобразует ваш XML прямо в объект.
Если вы можете использовать XSLT в декларативном стиле (хотя я не совсем согласен с тем, что это декларативный язык), то я считаю, что это полезно и выразительно.
Я написал веб-приложения, которые используют объектно-ориентированный язык (в моем случае C#) для обработки уровня данных/обработки, но выводят XML, а не HTML.Затем это может использоваться клиентами напрямую в качестве API данных или отображаться в виде HTML с помощью XSLT.Поскольку C# выдавал XML, который был структурно совместим с этим использованием, все было очень гладко, а логика представления оставалась декларативной.За этим было проще следить и изменять, чем отправлять теги из C#.
Однако, поскольку вам требуется больше логики обработки на уровне XSLT, она становится запутанной и многословной - даже если вы «понимаете» функциональный стиль.
Конечно, в наши дни я, вероятно, написал бы эти веб-приложения, используя интерфейс RESTful, и я думаю, что «языки» данных, такие как JSON, набирают обороты в областях, где XML традиционно преобразуется с помощью XSLT.Но на данный момент XSLT по-прежнему остается важной и полезной технологией.
Я провел много времени с XSLT и обнаружил, что, хотя в некоторых ситуациях это полезный инструмент, он определенно не может исправить все.Он очень хорошо работает для целей B2B, когда используется для перевода данных для машиночитаемого ввода/вывода XML.Я не думаю, что вы находитесь на неправильном пути в своих утверждениях о его ограничениях.Больше всего меня расстраивали нюансы реализации XSLT.
Возможно, вам стоит взглянуть на другие доступные языки разметки.Я считаю, что Джефф написал статью именно на эту тему, касающуюся переполнения стека.
Является ли HTML гуманным языком разметки?
Я бы посмотрел, что он написал.Вероятно, вы сможете найти пакет программного обеспечения, который делает то, что вы хотите, «из коробки» или, по крайней мере, очень близко, вместо того, чтобы писать свои собственные вещи с нуля.
В настоящее время мне поручено получить данные с общедоступного сайта (да, я знаю).К счастью, он соответствует xhtml, поэтому я могу использовать xslt для сбора необходимых мне данных.Полученное решение является читабельным, понятным и легко изменяемым в случае необходимости.Идеальный!
Раньше я использовал XSLT.Группа из 6 файлов .xslt (переработанных из одного большого) имела размер около 2750 строк задолго до того, как я переписал ее на C#.Код C# в настоящее время состоит из 4000 строк и содержит много логики;Я даже не хочу думать о том, что нужно было бы написать на XSLT.
Я сдался, когда понял, что отсутствие XPATH 2.0 существенно мешает моему прогрессу.
Чтобы ответить на ваши три вопроса:
- Я использовал XSLT один раз несколько лет назад.
- Я верю, что XSLT может быть правильным решением в определенных обстоятельствах.(Никогда не говори никогда)
- Я склонен согласиться с вашей оценкой, что это в основном полезно для «простых» преобразований.Но я думаю, что если вы хорошо понимаете XSLT, у вас есть основания использовать его для более крупных задач, таких как публикация веб-сайта в формате XML, преобразованного в HTML.
Я считаю, что причина, по которой многие разработчики не любят XSLT, заключается в том, что они не понимают фундаментально другую парадигму, на которой он основан.Но с недавним интересом к функциональному программированию мы можем увидеть возвращение XSLT...
Единственное место, где xslt действительно хорош, — это создание отчетов.Я обнаружил, что это двухэтапный процесс: на первом этапе данные отчета экспортируются в виде XML-файла, а на втором этапе создается визуальный отчет из XML с использованием xslt.Это позволяет создавать красивые визуальные отчеты, сохраняя при этом необработанные данные в качестве механизма проверки, если это необходимо.
В предыдущей компании мы много работали с XML и XSLT.И XML, и XSLT большие.
Да, нужно учиться, но тогда у вас есть мощный инструмент для работы с XML.И вы даже можете использовать XSLT в XSLT (что иногда может быть полезно).
Производительность также является проблемой (с очень большим XML), но вы можете решить ее, используя интеллектуальный XSLT и выполнив некоторую предварительную обработку (сгенерированного) XML.
Любой, кто знаком с XSLT, может изменить внешний вид готового продукта, поскольку он не скомпилирован.
Лично мне нравится XSLT, и вы, возможно, захотите дать упрощенный синтаксис внешний вид (никаких явных шаблонов, просто обычный старый HTML-файл с несколькими тегами XSLT для ввода в него значений), но он не для всех.
Возможно, вы просто хотите предложить своим авторам простой интерфейс Wiki или Markdown.Для этого тоже есть библиотеки, и если XSLT у вас не работает, возможно, XML не работает и у них.
XSLT не является завершающим этапом преобразования XML.Однако на основании предоставленной информации очень сложно судить, было ли это лучшим решением вашей проблемы или существуют другие, более эффективные и удобные в обслуживании подходы.Вы говорите, что авторы могли бы вводить свой контент в упрощенном формате – в каком?Текстовые поля?В какой HTML вы его конвертировали?Чтобы судить о том, является ли XSLT подходящим инструментом для данной работы, полезно более подробно узнать особенности этого преобразования.
Мне нравится использовать XSLT только для изменения древовидной структуры XML-документов.Я считаю обременительным делать что-либо, связанное с обработкой текста, и передавать это специальному сценарию, который я могу запустить до или после применения XSLT к XML-документу.
В XSLT 2.0 включено намного больше строковых функций, но я думаю, что они не подходят для этого языка, а реализаций XSLT 2.0 не так много.
