Варто XSLT? [зачинено]

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

Я все ще працюю над цим донині ( я насправді повинен працювати над цим зараз, замість того, щоб грати на SO ), і я бачу все більше і більше речей, які змушують мене думати, що рішення кинути XSLT було хороший.

Я знаю, що XSLT має своє місце в тому, що це прийнятий стандарт, і що якщо кожен пише власні перекладачі, 90% з них опиняться на TheDailyWTF . Але, враховуючи, що це мова функціонального стилю замість процедурного стилю, з яким знайома більшість програмістів, якщо хтось, хто починає такий проект, як мій власний, рекомендує вам піти шляхом, який я зробив, або дотримати його за допомогою XSLT ?

Переваги XSLT:

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

Недоліки XSLT:

• Це може бути нецензурно багатослівним - вам не доведеться цитувати буквальний XML, що фактично означає, що вам доведеться цитувати код. І не дуже. Але знову ж таки, це не набагато гірше, ніж ваш типовий SSI.
• Не робить певних речей, які більшість програмістів сприймає як належне. Наприклад, маніпуляція з струнами може бути справою. Це може призвести до «нещасних моментів», коли новачки розробляють код, а потім несамовито шукати в Інтернеті підказки, як реалізувати функції, які вони припускали, просто існуватимуть і не дають часу писати.
• Функціональна мова.

Один із способів отримати процедурну поведінку, до речі, - це зв'язати кілька перетворень разом. Після кожного кроку у вас є абсолютно новий DOM, над яким можна відобразити зміни цього кроку. Деякі процесори XSL мають розширення, щоб ефективно зробити це за один перетворення, але я забуваю деталі.

Отже, якщо ваш код здебільшого виводить і не так багато логіки, XSLT може бути дуже акуратним способом висловити це. Якщо логіки багато, але здебільшого форм, вбудованих у XSLT (виберіть усі елементи, схожі на бла, і для кожного виходу благ), це, ймовірно, буде досить дружньою обстановкою. Якщо ви хочете, щоб мислення XML-ishly весь час, тоді дайте 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 в 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. Все це дуже виразно і компактно, і, як правило, дуже добре розроблене і потужне для завдання, для якого вони розроблені.

Однак розробники програмного забезпечення, як правило, ненавидять такі мови, тому що вони настільки відрізняються від більшої кількості основних або процедурних мов, що їх важко вивчити та налагодити. Їх компактна природа в цілому дозволяє дуже легко зробити багато шкоди ненавмисно.

Тож, хоча XSLT є ефективним механізмом об'єднання даних у презентацію, він не працює у відділі зручності використання. Я вважаю, що тому він насправді не настиг.

Я пам’ятаю всю ажіотаж навколо XSLT, коли стандарт був нещодавно випущений. Всі хвилювання навколо можливості побудувати цілий інтерфейс HTML з "простою" трансформацією.

Подивимося, що це важко використовувати, майже неможливо налагодити, часто нестерпно повільно. Кінцевий результат майже завжди химерний і менш ідеальний.

Я швидше відгризну власну ногу, ніж використаю XSLT, поки є кращі способи робити речі. Все-таки він має свої місця, його користь для простих завдань перетворення.

Я широко використовував XSLT (а також XQuery) для різних речей - для генерування коду C ++ як частини процесу збирання, для створення документації з коментарів doc та в рамках програми, яка мусила працювати з XML взагалі та XHTML зокрема . Зокрема, генератор коду перевищував 10 000 рядків коду XSLT 2.0, розповсюджений приблизно на десяток окремих файлів (він робив багато речей - заголовки для клієнтів, видалення проксі-серверів / заглушок, COM-обгортки, .NET обгортки, ORM - щоб назвати декілька). Я успадкував його над іншим хлопцем, який не дуже добре розумів мову, і старші шматочки були, таким чином, безлад. Новіші речі, про які ми писали, здебільшого залишалися здоровими та читаними, але я не пам'ятаю жодних особливих проблем із цим. Це, звичайно, не було чим складніше, ніж робити це для C ++.

Якщо говорити про версії, то робота з XSLT 2.0 безумовно допомагає вам бути здоровими, але 1.0 все ще гаразд для більш простих перетворень. У своїй ніші це надзвичайно зручний інструмент, і продуктивність, яку ви отримуєте від певних доменних особливостей (головне, динамічна розсилка через відповідність шаблонів) важко відповідати. Незважаючи на сприйнятість сформульованості XML-синтаксису на основі XSLT, те саме в LINQ до 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 (lisp) для виконання перетворень XML, але я ще не досить далеко ще знаю, чи принесе мені такий підхід.

Особисто я використовував XSLT в абсолютно іншому контексті. Комп'ютерна гра, над якою я працював у той час, використовувала багато сторінок інтерфейсу, визначених за допомогою XML. Під час головного рефактора незабаром після випуску ми хотіли змінити структуру цих XML-документів. Ми зробили, що формат введення гри слідкує за значно кращою та зрозумілою схемою структурою.

XSLT здався ідеальним вибором для цього перекладу зі старого формату -> Новий формат. Протягом двох тижнів у мене було робоче перетворення зі старого на нове для наших сотень сторінок. Я також зміг скористатися ним, щоб отримати багато інформації про макет наших сторінок інтерфейсу користувача. Я створив списки, які компоненти були вкладені, в яких порівняно легко, який я потім використовував XSLT для запису в наші визначення схеми.

Крім того, виходячи з C ++, освоювати це було дуже цікавою та цікавою мовою.

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

Для вашого прикладу, я вважаю, що найкращою ідеєю було б створити свій власний XML-> XML-конверт, що відповідає вашій бізнес-логіці. Далі напишіть перекладач XSLT, який просто знає про форматування і не робить нічого розумного. Це може бути приємним серединою, але це повністю залежить від того, що ти робиш. Наявність на виході перекладача XSLT полегшує створення альтернативних форматів виводу - для друку, для мобільних пристроїв тощо.

Так, я його багато використовую. Використовуючи різні файли xslt, я можу використовувати одне і те ж джерело XML для створення декількох HTML-файлів поліглотів (X) (представляючи однакові дані по-різному), RSS-каналу, каналу Atom, файлу дескриптора RDF та фрагменту карти сайту .

Це не панацея. Є речі, які це робить добре, і речі, які не працюють добре, як і всі інші аспекти програмування, все полягає у використанні правильного інструменту для правильної роботи. Це інструмент, який варто мати у своїй панелі інструментів, але його слід використовувати лише тоді, коли це потрібно.

Я б точно рекомендував це не дотримуватися. Особливо, якщо ви використовуєте візуальну студію, яка має вбудовані засоби редагування, перегляду та налагодження для 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 serializaiton), а потім перетворюється в 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 налаштовували на використання OO під час написання 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, так це некрасиво. Так, до цього потрібно звикати. Але як тільки ви затримаєтесь (не повинно тривати довго IMO), це фактично плавне плавання. Скомпільовані перетворення запускаються досить швидко, на мій досвід, і ви, звичайно, можете налагодити в них.

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

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

Якщо ви можете використовувати XSLT в декларативному стилі (хоча я не зовсім згоден, що це декларативна мова), тоді я вважаю, що це корисно і виразно.

Я написав веб-програми, які використовують мову OO (у моєму випадку 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.