Стоит ли использовать XSLT? [закрыто]

Некоторое время назад я начал работу над проектом, в котором разработал схему 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 (выберите все элементы, которые выглядят как blah, и для каждого вывода blah), это, вероятно, будет довольно дружественной средой. Если вы всегда хотите думать в стиле 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 некрасиво, поэтому мы передаем данные через что-то вроде TagSoup(который генерирует правильные события SAX XML, по сути позволяя нам работать с 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 в некоторых случаях в первую очередь.

Подводя итог: это невероятно полезный инструмент, который можно иметь в своем арсенале, но он очень специализированный, поэтому он хорош, если вы используете его правильно и по прямому назначению. Я действительно хотел бы иметь правильную, родную .NET-реализацию XSLT 2.0.

Я использую XSLT (из-за отсутствия лучшей альтернативы), но не для презентации, а только для преобразования:

1. Я пишу короткие XSLT-преобразования для массового редактирования файлов maven pom.xml.

2. Я написал конвейер преобразований для создания схем XML из XMI (диаграммы UML). Какое-то время это работало, но в конце концов стало слишком сложным, и нам пришлось выносить его за сарай.

3. Я использовал преобразования для рефакторинга XML-схем.

4. Я обошел некоторые ограничения в XSLT, используя его для создания XSLT для выполнения реальной работы. (Вы когда-нибудь пытались написать XSLT, который производит вывод с использованием пространств имен, которые неизвестны до времени выполнения?)

Я продолжаю возвращаться к нему, потому что он лучше справляется с обработкой XML, чем другие подходы, которые я пробовал, которые казались ненужными с потерями или просто неправильно понимали XML. XSLT неприятен, но я считаю, что использование Oxygen делает его терпимым.

Тем не менее, я исследую использование Clojure (шепелявого) для выполнения преобразований XML, но я еще не продвинулся достаточно далеко, чтобы знать, принесет ли мне этот подход пользу.

Лично я использовал XSLT в совершенно другом контексте. В компьютерной игре, над которой я работал в то время, использовалось множество страниц пользовательского интерфейса, определенных с помощью XML. Во время крупного рефакторинга вскоре после выпуска мы хотели изменить структуру этих XML-документов. Мы сделали входной формат игры гораздо более понятным и учитывающим схему.

XSLT казался идеальным выбором для этого перевода из старого формата в новый формат. В течение двух недель у меня было рабочее преобразование из старых в новые для наших сотен страниц. Я также смог использовать его для извлечения большого количества информации о макете наших страниц пользовательского интерфейса. Я создал списки, в которые относительно легко были встроены компоненты, которые затем использовал XSLT для записи в определения наших схем.

Кроме того, благодаря опыту работы с C ++, освоить этот язык было очень весело и интересно.

Я считаю, что это фантастический инструмент для перевода XML из одного формата в другой. Однако это не единственный способ определить алгоритм, который принимает XML на входе и что-то выводит . Если ваш алгоритм достаточно сложен, тот факт, что входными данными является XML, становится несущественным для вашего выбора инструмента - например, сверните свой собственный в C ++ / Python / где угодно.

Конкретно для вашего примера, я бы предположил, что лучшей идеей было бы создать собственное преобразование XML-> XML, которое следует вашей бизнес-логике. Затем напишите переводчик XSLT, который просто знает о форматировании и не делает ничего умного. Это может быть хорошей золотой серединой, но это полностью зависит от того, что вы делаете. Наличие переводчика XSLT на выходе упрощает создание альтернативных форматов вывода - для печати, для мобильных устройств и т. Д.

Да, я часто им пользуюсь. Используя разные файлы xslt, я могу использовать один и тот же источник XML для создания нескольких файлов HTML-полиглота (X) (представляющих одни и те же данные по-разному), канала 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 ... довольно сложно держать в уме все 3 разных XML-документа.

Ваша ситуация немного отличается: вместо того, чтобы создавать каждую страницу в XSLT, как это сделал я, вам нужно написать только ОДИН бит кода в XSLT (код для преобразования из шаблонов в отображение). Но похоже, что вы, возможно, столкнулись с той же проблемой, что и я. Я бы сказал, что попытка интерпретировать простой DSL на основе XML (предметно-ориентированный язык), как это делаете вы, НЕ является одной из сильных сторон XSLT. (Хотя он МОЖЕТ сделать эту работу ... в конце концов, он завершен по Тьюрингу!)

Однако если то, что у вас было, было проще: у вас есть данные в одном формате XML и вы хотите внести в него простые изменения - не DSL с полным описанием страницы, а несколько простых и простых модификаций, тогда XSLT - отличный инструмент для этой цели. Его декларативный (а не процедурный) характер на самом деле является преимуществом для этой цели.

- Майкл Чермсайд

С XSLT сложно работать, но как только вы овладеете им, вы получите очень полное представление о DOM и схеме. Если вы тоже XPath, то вы на пути к изучению функционального программирования, и это откроет вам новые методы и способы решения проблем. В некоторых случаях последовательное преобразование более действенно, чем процедурные решения.

Я широко использую XSLT для пользовательского интерфейса в стиле MVC. Модель «сериализуется» в xml (не через сериализацию xml), а затем конвертируется в html через xslt. Преимущество перед ASP.NET заключается в естественной интеграции с XPath и более строгих требованиях к правильному формату (гораздо легче рассуждать о структуре документа в xslt, чем в большинстве других языков).

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

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

Я использовал XML, XSD и XSLT в проекте интеграции между очень непохожими системами баз данных где-то в 2004 году. Мне пришлось изучить 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 с помощью пользовательских функций расширения:

• Документация MSDN
• CSharpFriends: Учебник

Я поддерживаю систему онлайн-документации для своей компании. Писатели создают документацию на 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 значительно мешает моему прогрессу.

Чтобы ответить на ваши три вопроса:

1. Несколько лет назад я использовал XSLT.
2. Я действительно считаю, что XSLT может быть правильным решением при определенных обстоятельствах. (Никогда не говори никогда)
3. Я склонен согласиться с вашей оценкой, что это в основном полезно для «простых» преобразований. Но я думаю, что если вы хорошо понимаете 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.