Чи є якісь вагомі причини використовувати, вивчати чи рекомендувати XSLT? [зачинено]

Я розробник останні 8 років. Ми використовували XSLT в основному для перетворення XML в HTML. Ми також використовували його для перетворення XML в XML.

Але ми маємо заміну на все зараз. HTML можна зручно створювати за допомогою мов програмування, таких як ASP.Net. XML можна читати та обробляти будь-якими стандартними мовами високого рівня. Оскільки програмування в XSLT мало складне, будь-хто з них вважає за краще працювати над останніми мовами програмування.

Тепер моє запитання: чи буде XSLT вагомим вибором у майбутньому, не враховуючи факту збереження вже розробленої XSLT? Чи можу я рекомендувати нових програмістів для вивчення XSLT?

Є кілька важливих випадків, коли XSLT може стати хорошим вибором:

• Програмне забезпечення ETL ( Extract, Transform, Load ) може в деяких випадках використовувати XSLT. Наприклад, це може бути хорошим вибором, коли витягнуті дані та дані для завантаження знаходяться у форматі XML, і де перетворення може бути змінено без необхідності перекомпілювати додаток.

• Деякі програми, які зберігають дані в XML, використовують XSLT для представлення цих даних у читаному для людини форматі¹. Наприклад, Windows Live Messenger зберігає слід повідомлень як XML, але коли ви відкриваєте історію у самій WLM, вона показує вам гарну таблицю, яка насправді є HTML, побудованою за допомогою XSLT.

• Деякі веб-сайти, орієнтовані на розробників або орієнтовані на дані, можливо, захочуть надати доступ до XML, якщо наміром є використання сторінок веб-сайту програмно². Це якось приємніше, ніж використовувати HTML-парсери, тим більше, що HTML-код можна змінити в будь-який момент.

• При використанні на веб-сайтах XSLT дозволяє чітко розмежовувати HTML та код, що дає змогу найняти розробника для коду та іншого розробника для HTML / CSS. Дивіться пункт 1 у моїй відповіді на інше запитання .

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

Чи можете ви порекомендувати нових програмістів для вивчення XSLT? Звичайно! Не тільки XSLT може використовуватися в деяких обставинах, коли інші підходи будуть складнішими, але і XSLT має дуже специфічний підхід, якого не мають інші мови.

^{Під цим я маю на увазі, що XML насправді не читається людиною: якщо ви попросите людину, яка не працює в ІТ, прочитати XML, він буде жахнутий
² Я знаю, що є веб-сервіси. Але іноді просто простіше і простіше на кожній сторінці побудувати динамічний об’єкт, потім серіалізувати його в XML, а потім перетворити його в HTML через XSLT або дозволити боту отримати доступ до XML безпосередньо.}

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

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

Так чи інакше, ви можете вивчити XSLT за лічені дні, а може й тижні. Вам не зашкодить зробити досвід з перших рук. Просто дайте йому постріл. Принаймні варто докласти зусиль, щоб зберегти подібний зразок (перетворення на основі правил) для подальшого використання. Це одне виправдовує вивчення XSLT.

Хм, мені цікаво, чи API-інтерфейси високого рівня, які створюють HTML з коду, використовують будь-який XSLT "під кришкою" ...

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

Так.

Візьмемо хороший приклад: одиниці тестових звітів у постійній інтеграції. Більшість програм тестування та охоплення коду просто видають тони нечитабельного XML. Але за допомогою декількох простих XSLT можна створити з тих же даних десяток корисних звітів. І інші люди можуть повторно використовувати ці звіти.

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

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

Для багатьох завдань, які я бачу, як XSLT використовується (і завдання, якими я його використовую для себе), написання Java або ASP-коду для виконання завдання було б жахливою тратою бюджету вашого роботодавця. Але, можливо, ні, якщо вам здається, що ви добре пишете Java і погано пишете XSLT.

XSLT не читається людиною. Метаінформація (теги) займає занадто багато місця над реальною інформацією (текст, запити xpath). Хороший код повинен виглядати як документація, і це, як правило, не стосується XSLT. Це досить хороший формат збереження для інструментів картографування.

Хороша мова перетворення повинна дозволяти попередньо переглядати результат перетворення та переглядати потік перетворень (ЯКЩО, ELSE, FOR, WHILE) одночасно. це важливо для ремонту. Щодо цього аспекту швидкість або GenearateXY кращі, ніж XSLT. GenerateXY навіть трохи краще, оскільки він розділяє попередній перегляд та потік, тоді як зі швидкістю вам доведеться, на жаль, порушити відступ попереднього перегляду, щоб забезпечити читабельний потік.

Єдиним хорошим моментом XSLT є те, що він дбає про модульність, використовуючи та навіть зловживаючи елементами "xsl: template". Проблема в цьому полягає в тому, що це добре для мови обробки даних (Java, C, ...), але дуже другорядне для мови презентації.

Справді

Щось, мабуть, один день замінить XSLT, оскільки це вивчити та використовувати трохи громіздко. Однак в даний час немає доступних шаблонів / мов перетворення afaik, який є настільки ж гнучким та "чистим" у своїй реалізації.

XSL-T можна використовувати для кількох різних цілей:

• Ви можете "створити" вміст у відповідному форматі HTML з даних за допомогою шаблону
• Ви можете конвертувати з одного формату XML в інший
• Ви можете маніпулювати xml в іншому форматі, можливо, показати підмножину

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

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

Далі - ASP.Net. Ми розміщуємо наш макет на нашій сторінці asp і вставляємо ззаду якийсь код для динамічних частин. Інша альтернатива - відмовитися від частини верстки та генерувати все, скажімо, із бази даних та використовуючи C #, створюючи бажаний вихід.

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

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

За допомогою XSLT ви можете просто створити шаблон для певного тегу, як такий, який є, або в контексті його батьківського, так що він відображається інакше, якщо він, наприклад, є parentet чимось іншим.

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

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

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

Власне кажучи, я думаю, що для представлення даних ефективніше використовувати XSL, ніж іншу мову. Наприклад, ви можете представити XML у вигляді PDF за допомогою XSL-FO, і ви можете керувати кожним дюймом, але якщо, наприклад, працюєте з RDLC (.NET), ви побачите, що дуже важко представити саме те, що ви хочете.

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

Я працюю в компанії з інтеграції даних, і ми використовуємо XSLT з нашими власними інструментами як чудове рішення, що включає XML в HTML / XML / Ascii.