Стоит ли XSLT?

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

Я использую 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/etc - это те, у кого проблемы с языком (переменные - переменные в смысле алгебры, а не процедурное программирование, например). Что многие из людей, отвечающих здесь - я никогда не встречался с 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 является примером декларативного программирования.

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

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

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

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

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

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

Я использовал 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я использовал 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 при написании С++.

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

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

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

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

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

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

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

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

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

Я обнаружил, что 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 - отличный инструмент для это цель. Этот декларативный (не процедурный) характер на самом деле является преимуществом для этой цели.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Microsoft Windows имеет MSXML, который установлен в базовой системе с по крайней мере Windows 2000. Он может использоваться как из MSIE, из командной строки (используя WSH) или из приложений Office
• Java Runtime Environment (JRE) имеет среду выполнения XSLT, а JRE установлена ​​на большинстве настольных компьютеров.
• У почти всех основных веб-браузеров есть один. Операция является исключением.
• Существуют бесплатные реализации, установленные по умолчанию в основных операционных системах на базе GNU (libxslt, xsltproc)
• Я не проверял MacOS X, но у него есть хотя бы реализация в Safari

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

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

У меня был довольно хороший опыт работы с XSLT, но я не преобразовывался в HTML. Может быть, компиляция XSLT-HTML очень сложна для выполнения.

С точки зрения максимальной производительности вам было бы лучше использовать одну из библиотек jQuery-стиля - pyQuery, phpQuery и т.д. Большинство библиотек XML suck и XSLT - это, по сути, просто еще одна библиотека XML, упакованная как полноценный язык, но без приличного набор инструментов. jQuery позволяет безумно легко перемещаться и манипулировать данными стиля XML на выбранном вами языке.

Я использую XSLT для исправления ошибок в очень сложных xml файлах. Поэтому вместо обработки ошибок в xml я использую xslt для их исправления.

Это здорово. Потому что язык настолько силен и подходит для использования xml. Для того, чтобы делать то же самое на языке программирования на языке, мне понадобилось очень много времени, чтобы адаптировать мой код каждый раз, когда возникает новый вкус.

Его также использовать для миграции визуальных студийных решений, не позволяя Microsoft решать, какие вещи нужно изменить. Так конвертируйте одно решение. Проверьте, что изменилось. Отмените действия, которые вы не хотите изменять, и запустите xslt script, выполнив задание во всех файлах.

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

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

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

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

Если XSLT был продвинут как какой-то SQL для XML, все будет немного иначе. Во-первых, люди даже не потрудились посмотреть на это. И те, кто это сделал, не были бы удивлены болью.

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

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

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

Это будущее? может быть, нет, может быть, есть лучшие решения.

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

По-моему Да.

Для отличного примера очень крутого использования XSLT, проверьте мир метели оружия Warcraft.

http://www.wowarmory.com

Говоря о взаимозаменяемости, XML является стандартом для хранения информации. Множество инструментов выводит результат в XML и что лучше (или проще) способ его представить, чем встраивать браузер в приложение и форматировать XML и помещать его в браузер.

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

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

Но: Это довольно сложная кривая обучения, поскольку она не процедурная. Если вы привыкли к процедурному программированию (C, Java, Perl, PHP и т.д.), Вы пропустите много общих структур, или вы будете задаваться вопросом о том, что просто удача кубизма, а иногда и не очень читаемая неподготовленным взглядом. Например, написание кода "resuseable": если вам нужно что-то делать снова и снова в разных местах, в процедурном программировании вы определяете функцию для этого. Вы также можете достичь таких вещей в XSLT, но это для большего количества кода для записи и не так читаемо/понятно, как обычная функция.

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

Итак, как вывод: я больше не вижу XSLT как "окончательное" решение. На самом деле это боль, чтобы читать или писать некоторые конструкции в XSLT. В большинстве случаев вам придется подумать о приложении: для простого преобразования я, вероятно, снова воспользуюсь XSLT. Но для более сложного программного обеспечения я больше не буду использовать его.

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

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

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

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

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

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

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

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

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

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

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