Стоит ли XSLT?

Ответ 1

Преимущества XSLT:

• Домен, специфичный для XML, поэтому, к примеру, не нужно указывать литерал XML на выходе.
• Поддерживает XPath/XQuery, который может быть хорошим способом запроса DOM, таким же образом, что регулярные выражения могут быть хорошим способом запроса строк.
• Функциональный язык.

Недостатки XSLT:

• Может быть неприлично многословным - вам не нужно указывать буквальный XML, что фактически означает, что вам нужно процитировать код. И не очень красиво. Но опять же, это не намного хуже, чем ваш типичный SSI.
• Не делает определенные вещи, которые большинство программистов принимают как должное. Например, манипуляция строк может быть сложной задачей. Это может привести к "неудачным моментам", когда новички разрабатывают код, а затем отчаянно ищут в Интернете подсказки о том, как реализовать функции, которые они предполагали, просто были там и не дали себе времени для написания.
• Функциональный язык.

Одним из способов получить процедурное поведение, кстати, является объединение нескольких преобразований вместе. После каждого шага у вас есть новый DOM для работы, который отражает изменения на этом этапе. Некоторые XSL-процессоры имеют расширения для эффективного выполнения этого в одном преобразовании, но я забываю детали.

Итак, если ваш код в основном выводится и не так много логики, XSLT может быть очень аккуратным способом его выразить. Если есть много логики, но в основном из форм, которые встроены в XSLT (выберите все элементы, которые выглядят как blah, и для каждого из них выводят blah), это, вероятно, будет довольно дружественной средой. Если вам кажется, что вы постоянно идете XML-ishly, дайте XSLT 2 пойти.

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

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

Ответ 2

Столь большая негативность!

Я использую XSLT в течение нескольких лет и искренне люблю его. Главное, что вы должны понимать, это то, что это не язык программирования, это шаблонный язык (и в этом отношении я считаю его неописуемо превосходящим asp.net/spit).

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

Затем существуют возможности утилиты: вымывание пространств имен, распознавание разрозненных определений схем, объединение документов.

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

Случай использования в реальном мире: я написал приложение, которое обрабатывает XML-документы в памяти во всей системе и преобразуется в JSON, HTML или XML по просьбе конечного пользователя. У меня был случайный запрос предоставить данные Excel. Бывший коллега сделал что-то подобное программно, но ему нужен модуль из нескольких файлов классов и что на сервере установлен MS Office! Оказывается, в Excel есть XSD: новая функциональность с минимальным воздействием базового кода за 3 часа.

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

Очевидно, я твердо верю, что это "стоит того".

Ответ 3

Я должен признать предубеждение здесь, потому что я учу XSLT для жизни. Но, возможно, стоит покрыть области, в которых я вижу своих учеников. Они разделились на три группы в целом: публикация, банковское дело и Интернет.

Многие из ответов до сих пор можно было бы обобщить как "это не полезно для создания веб-сайтов" или "это не похоже на язык X". Многие технические люди проходят свою карьеру без участия функциональных/декларативных языков. Когда я преподаю, опытные люди Java/VB/C/etc - это те, у кого проблемы с языком (переменные - переменные в смысле алгебры, а не процедурное программирование, например). Что многие из людей, отвечающих здесь - я никогда не встречался с Java, но из-за этого я не собираюсь критиковать язык.

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

Ученики банковского дела, которые я вижу, используют поле DataPower в целом. Это устройство XML, и оно использовалось для общения между "говорящими" различными диалектами XML. Трансформация с одного языка XML на другой почти тривиальна в XSLT, и число студентов, посещающих мои курсы по этому поводу, увеличивается.

Последний набор учеников, которых я вижу, исходит из публикации (например, я). Эти люди, как правило, имеют огромные документы в XML (поверьте мне, публикация, поскольку индустрия очень сильно вписывается в XML), в течение многих лет существует техническая публикация, и сейчас публикуется публикация в области торговли. Эти документы должны быть обработаны (DocBook to ePub приходит на ум здесь).

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

Это, конечно, не умирающий язык (объем работы, который я получаю, мне подсказывает). Прямо сейчас, это немного "застряло", пока Microsoft не закончит свою (очень позднюю) реализацию XSLT 2. Но она все еще существует и, похоже, сильно зависит от моей точки зрения.

Ответ 4

Мы широко используем 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. Это не самый простой язык в мире, но он определенно не мертв, и с моей точки зрения все еще есть много хороших применений.

Ответ 5

XSLT является примером декларативного программирования.

Другие примеры декларативных языков программирования включают регулярные выражения, Prolog и SQL. Все они очень выразительны и компактны и, как правило, очень хорошо разработаны и мощны для задачи, для которой они разработаны.

Однако разработчики программного обеспечения, как правило, ненавидят такие языки, потому что они настолько отличаются от более распространенных OO или процедурных языков, которые им трудно изучать и отлаживать. Их компактный характер, как правило, делает очень легким сделать много повреждений непреднамеренно.

Таким образом, хотя XSLT является эффективным механизмом для объединения данных в презентацию, он не работает в отделе простоты использования. Я верю, что на самом деле это не так сильно.

Ответ 6

Я помню всю шумиху вокруг XSLT, когда стандарт был недавно выпущен. Все волнение вокруг возможности создания всего HTML-интерфейса с "простым" преобразованием.

Давайте посмотрим правде в глаза, его трудно использовать, почти невозможно отлаживать, часто невыносимо медленно. Конечный результат почти всегда причудливый и менее идеальный.

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

Ответ 7

Я использовал XSLT (а также XQuery) для разных целей - для генерации кода на С++ как часть процесса сборки, для создания документации из комментариев в формате doc и в приложении, которое должно было работать с XML вообще и XHTML в особенно много. Генератор кода, в частности, превышал 10 000 строк кода XSLT 2.0, распространялся примерно на десяток отдельных файлов (он делал много вещей - заголовки для клиентов, удаляя прокси/заглушки, обертки COM, обертки .NET, ORM - для обозначения немного). Я унаследовал это от другого парня, который не очень хорошо понимал язык, а старые биты были, следовательно, довольно беспорядочным. Однако новые материалы, которые мы писали, были в основном сохранены и понятны, и я не помню каких-либо особых проблем с достижением этого. Это было, конечно, не сложнее, чем делать это для С++.

Говоря о версиях, работа с XSLT 2.0 определенно помогает поддерживать нормальную работу, но 1.0 все еще в порядке для более простых преобразований. В своей нише это чрезвычайно удобный инструмент, и производительность, которую вы получаете от определенных специфических для домена функций (что самое главное, динамическая отправка через сопоставление с шаблонами) трудно сопоставить. Несмотря на воспринимаемую многословность синтаксиса на основе XML XSLT, одно и то же в LINQ to XML (даже в VB с XML-литералами), как правило, в несколько раз больше. Довольно часто, однако, он получает незаслуженную флэку из-за ненужного использования XML в некотором случае в первую очередь.

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

Ответ 8

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

• Я пишу короткие XSLT-преобразования, чтобы делать массовые изменения в наших файлах maven pom.xml.

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

• Я использовал преобразования для реорганизации XML-схем.

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

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

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

Ответ 9

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

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

Кроме того, исходя из фона С++, это был очень интересный и интересный язык для освоения.

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

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

Ответ 10

Да, я использую это много. Используя разные файлы xslt, я могу использовать один и тот же источник XML для создания нескольких HTML файлов polyglot (X) (представляющих одни и те же данные по-разному), RSS-фида, фида Atom, файла дескриптора RDF и фрагмента карты сайта.

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

Ответ 11

Я бы определенно рекомендовал выступить. В частности, если вы используете визуальную студию, которая имеет встроенные средства редактирования, просмотра и отладки для XSLT.

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

W3schools имеет две статьи, которые имеют особую ценность: http://www.w3schools.com/xpath/xpath_functions.asp http://www.w3schools.com/xsl/xsl_functions.asp

Ответ 12

Я обнаружил, что XSLT работать довольно сложно.

У меня был опыт работы над системой, несколько похожей на ту, которую вы описываете. Моя компания отметила, что данные, которые мы возвращали из "среднего уровня", были в XML и что страницы должны отображаться в HTML, что также может быть XHTML, и они слышали, что XSL является стандартом для преобразования между XML форматы. Таким образом, "архитекторы" (под которыми я имею в виду людей, которые думают о глубоких дизайнерских мыслях, но, по-видимому, никогда не кодируют), решили, что наш фронт-уровень будет реализован путем написания сценариев XSLT, которые преобразуют данные в XHTML для отображения.

Выбор оказался катастрофическим. XSLT, оказывается, это боль, чтобы писать. И поэтому все наши страницы трудно писать и поддерживать. Мы бы намного лучше использовали JSP (это было на Java) или какой-то подобный подход, который использовал один вид разметки (угловые скобки) для формата вывода (HTML) и другой вид разметки (например, <%...% > ) для метаданных. Самая запутанная вещь в XSLT заключается в том, что она написана в XML, и она переводится с XML на XML... довольно сложно хранить все 3 разных XML-документа прямо в одном уме.

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

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

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

Ответ 13

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

Ответ 14

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

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

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

Ответ 15

Я использовал XML, XSD и XSLT в проекте интеграции между очень диссонированными системами БД в 2004 году. Мне пришлось изучать XSD и XSLT с нуля, но это было непросто. Самое замечательное в этих инструментах было то, что он позволил мне написать независимый от С++ код, полагающийся на XSD и XSLT для проверки/проверки, а затем преобразования XML-документов. Измените формат данных, измените документы XSD и XSLT, а не код С++, который использовал библиотеки Xerces.

Для интереса: основной XSD составлял 150 КБ, а средний размер XSLT был < 5KB IIRC.

Другим большим преимуществом является то, что XSD является спецификационным документом, на котором основан XSLT. Они работают в гармонии. И спецификации в наши дни редко встречаются в разработке программного обеспечения.

Хотя у меня не было слишком много проблем с изучением декларативного характера XSD и XSLT, я обнаружил, что другие программисты на C/С++ испытывали большие трудности в адаптации к декларативному пути. Когда они увидели, что это так, а процедурные они пробормотали, теперь, когда я понимаю! И они продолжили (каламбур?), Чтобы написать процедурный XSLT! Дело в том, что вам нужно изучить XPath и понять оси XML. Напоминает мне о программистах старого времени, которые настраиваются на использование OO при написании С++.

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

Ответ 16

Раньше я думал, что XSLT - отличная идея. Я имею в виду, что это отличная идея.

В случае сбоя выполняется выполнение.

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

Хорошо, вы могли бы "использовать" его - я думаю, что это было отчасти моментом его дизайна, но второе - неудачным: все инструменты XSLT на рынке, просто... дерьмо!

Ответ 17

спецификация XSLT определяет XSLT как "язык для преобразования документов XML в другие XML-документы". Если вы пытаетесь сделать что-то, кроме самой основной обработки данных в XSLT, вероятно, есть лучшие решения.

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

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

Ответ 18

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

Использование альтернативного подхода и синтаксический анализ XML в коде может быть столь же неприятным, и вы действительно хотите использовать какую-то технологию XML-маршаллинга/привязки (например, JiBX на Java), которая преобразует ваш XML прямо в объект.

Ответ 19

Я поддерживаю систему онлайн-документации для своей компании. Авторы создают документацию в SGML (язык, подобный xml). SGML затем объединяется с XSLT и преобразуется в HTML.

Это позволяет нам легко вносить изменения в макет документации без какой-либо кодировки. Это просто вопрос об изменении XSLT.

Это хорошо для нас. В нашем случае это документ только для чтения. Пользователь не взаимодействует с документацией.

Кроме того, с помощью XSLT вы работаете ближе к своему проблемному домену (HTML). Я всегда считаю, что это хорошая идея.

Наконец, если ваша текущая система РАБОТАЕТ, оставьте ее в покое. Я бы никогда не предложил уничтожить существующий код. Если бы я начинал с нуля, я бы использовал XSLT, но в вашем случае я использовал бы то, что у вас есть.

Ответ 20

Это сводится к тому, для чего вам это нужно. Его основная сила - легкая ремонтопригодность преобразования, и написание собственного анализатора, как правило, стирает это. С учетом сказанного, иногда система небольшая и простая и на самом деле не нуждается в "причудливом" решении. Пока ваш конструктор, основанный на кодах, заменяется без изменения другого кода, не имеет большого значения.

Что касается уродства XSL, да это уродливо. Да, к этому нужно привыкнуть. Но как только вы его повесите (недолго, чтобы IMO), это действительно плавное плавание. Скомпилированные преобразования выполняются довольно быстро в моем опыте, и вы можете, конечно, отлаживать их.

Ответ 21

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

Я написал веб-приложения, которые используют язык OO (С# в моем случае) для обработки уровня данных/обработки, но выводят XML, а не HTML. Затем это может быть использовано непосредственно клиентами как API данных или отображено как HTML с помощью XSLT. Поскольку С# выводил XML, который был структурно совместим с этим использованием, все было очень гладко, а логика представления оставалась декларативной. Легче было следить и изменять, чем отправлять теги из С#.

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

Конечно, в эти дни я бы, наверное, написал эти веб-приложения, используя интерфейс RESTful, и я думаю, что данные "языки", такие как JSON, приобретают тягу в областях, которые XML традиционно трансформировал XSLT. Но на данный момент XSLT по-прежнему остается важной и полезной технологией.

Ответ 22

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

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

Является ли HTML гуманным языком разметки?

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

Ответ 23

В настоящее время мне поручено соскабливать данные с общедоступного сайта (да, я знаю). К счастью, он соответствует xhtml, поэтому я могу использовать xslt для сбора необходимых мне данных. Полученное решение является читаемым, чистым и легко меняющимся в случае необходимости. Отлично!

Ответ 24

Раньше я использовал XSLT. Группа из 6 файлов .xslt(реорганизована из одного большого) составляла около 2750 строк, прежде чем я переписал ее на С#. В настоящее время код С# содержит 4000 строк, содержащих много логики; Я даже не хочу думать о том, что нужно было бы написать в XSLT.

То, что я сдался, - это когда я понял, что отсутствие XPATH 2.0 значительно ухудшает мои успехи.

Ответ 25

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

• Я использовал XSLT несколько лет назад.
• Я считаю, что XSLT может быть правильным решением при определенных обстоятельствах. (Никогда не говори никогда)
• Я склонен согласиться с вашей оценкой, что он в основном полезен для "простых" преобразований. Но я думаю, что до тех пор, пока вы хорошо понимаете XSLT, есть аргумент в пользу его использования для более крупных задач, таких как публикация веб-сайта, как XML, преобразованный в HTML.

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

Ответ 26

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

Ответ 27

В предыдущей компании мы много работали с XML и XSLT. И XML, и XSLT большие.

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

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

Любой, кто знает XSLT, может изменить внешний вид готового продукта, потому что он не скомпилирован.

Ответ 28

Мне лично нравится XSLT, и вы можете дать упрощенный синтаксис внешний вид (без явных шаблонов, просто обычный старый HTML файл с несколькими тегами XSLT, чтобы вставлять в него значения), но это не для всех.

Возможно, вы просто хотите предложить своим авторам простой интерфейс Wiki или Markdown. Для этого есть библиотеки, и если XSLT не работает для вас, возможно, XML тоже не работает для них.

Ответ 29

XSLT не является окончательным преобразованием xml. Однако очень сложно судить на основе предоставленной информации, если бы это было наилучшим решением вашей проблемы или если есть другие более эффективные и поддерживаемые подходы. Вы говорите, что авторы могли ввести свой контент в упрощенном формате - в каком формате? Текстовые поля? В какой html вы его конвертировали? Чтобы судить, является ли XSLT правильным инструментом для работы, это поможет более подробно узнать особенности этого преобразования.

Ответ 30

Я тоже совершил набеги в мир XSLT, и я обнаружил, что это немного неудобно в местах. Я думаю, что моя главная проблема заключалась в трудности преобразования XML-данных "чистых данных" в полную HTML-страницу. Оглядываясь назад, возможно, используя XSLT для генерации фрагмента страницы, который может быть составлен вместе с другими фрагментами с использованием сценариев на стороне сервера (например, SSI), я бы разрешил многие из моих проблем.

Одна из возможных ошибок заключалась в том, чтобы попытаться построить общий макет страницы, чтобы окружить мои данные, импортировав XHTML или другие XML-данные с помощью функции document().

Другая ошибка заключалась в том, чтобы делать такие программные вещи, как создание общего шаблона для генерации таблиц данных XML с логикой, которая делала такие вещи, как использование разных цветов фона для строк с определенными значениями и позволяет указать некоторые столбцы для фильтрации,

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

Что я получил? Ну, источник страницы - это данные XML прямо там и доступны для зрителя. Данные и презентация аккуратно разделены.

Я сделал бы это снова? Наверное, нет, если я действительно не хотел разделять данные/презентацию на странице static. В противном случае, вероятно, я бы написал приложение Rails или Java EE, которое могло бы генерировать представление XML или представление HTML с помощью шаблонов - все преимущества, но с гораздо более естественным (для меня) языком программирования у меня под рукой.