Что предотвращает широкое использование XSLT для веб-страниц?
Исключениями является несколько дорогостоящий эффект, если, например, у Вас есть пользователь, который обеспечивает неверный пароль, это обычно - лучшая идея пасовать назад флаг отказа или некоторый другой индикатор, что это недопустимо.
Это происходит из-за способа, которым исключения обработаны, истинный плохой вход, и уникальные критические объекты остановки должны быть исключениями, но не отказавшей информацией о входе в систему
11 ответов
- Это чрезвычайно многословно
- Трудно отследить (в сложной системе), как / где / почему / когда вызывается шаблон
- Поскольку вывод должен быть правильно сформирован, вы можете ' У вас нет шаблона, который «открывает» тег HEAD или BODY, о котором вы потом будете беспокоиться о закрытии в другом месте. Это отстой, когда вы хотите иметь возможность ставить в очередь биты кода для перехода в HEAD, когда вы обрабатываете то, что будет в BODY.
- Не так просто перемещаться по коду, как следующие вызовы методов
- Вывод чего-то вроде условного комментария IE очень сбивает с толку из-за необходимости экранирования
- Построение строки HTML путем добавления битов просто не работает. Это можно преодолеть, построив строку HTML по крупицам в XSL-коде, но это становится довольно сложным.
Однако больше всего (ИМХО) он добавляет дополнительный уровень к процессу, который вас мало «покупает».
например, обычно у вас есть:
DB > SQL > [JAVA|PHP|ASP|Python|Ruby] > HTML
, но если вы добавите XML и XSL, вы Мы добавили шаги, которые (может быть) трудно оправдать
DB > SQL > [JAVA|PHP|ASP|Python|Ruby] > XML > XSL > HTML
, что наличие данных в удобном и универсально заменяемом XML-формате - это здорово, но если вам это не нужно , все, что вы сделали, это добавить шаги.
Теперь я не должен слишком сильно отказываться от XSL, потому что я использую его постоянно и ценю некоторые из мощных возможностей, которые он предоставляет. Однако всем, кто решает, хотят ли они его использовать, убедитесь, что у вас есть потребность , прежде чем приступать к делу.
Blizzard Entertainment, похоже, нравится XSLT. Их сайт World of Warcraft Armory полностью реализован с его помощью. Осмотрите сайт, используя исходный код.
Я думаю, что отчасти проблема заключается в том, что программирование на XSLT имеет некоторые атрибуты функционального языка (см. этот ответ , чтобы узнать, почему оно не полностью функционально).
Таким образом, он требует подхода, отличного от «обычного» императивного мышления, и это удержит некоторых людей от полного изучения его (я не отвергаю функциональное программирование, кстати, но в мире веб-клиента / сервера это не то наиболее распространенная парадигма).
В мире Java это обычно воспринималось как медлительный и требовательный к памяти. Я уверен, что некоторые из них были анекдотичными и, возможно, частично были результатом первых виртуальных машин. Однако я отмечаю, что аппаратные ускорители XML доступны и находятся за интерфейсом JAXP, так что, возможно, все еще существует проблема скорости?
Есть несколько проблем, связанных с внедрением XSLT, в том числе проблемы с браузером. Например, плагин NoScript для Firefox, предназначенный для блокировки вредоносного JavaScript, также блокирует XSLT на неизвестных страницах. Не забывайте, что переключение на поддомен или другой протокол заставит IE отреагировать на него как на нарушение той же политики происхождения. Тем не менее, XML + XSLT, даже если он используется только для ограниченного числа случаев, весьма полезен. См. Веб-сайт WoW в качестве примера хорошо реализованного XML + XSLT.
XSLT в браузере прямо сейчас, потому что малейшая ошибка при генерации действительного ввода XML может привести к тому, что ваша страница будет отображаться пустой, но есть продукт под названием Deliverance , который запускается на сервере для создания различных веб-приложений. на сайте используется одна и та же тема.
XSLT на удивление быстр. Это будет намного быстрее, чем типичный интерпретируемый язык шаблонов на сервере.
XSLT - уродливый, уродливый язык шаблонов. У него есть некоторые преимущества, но также отсутствуют некоторые важные функции. Django содержит язык шаблонов для дизайнеров, обеспечивающий простой доступ к элементам данных. Они рассматривали XLST до , но считают, что его легко заменить. Пользователи PHP могут предпочесть что-то вроде Smarty .
Очевидно, ваш вопрос сосредоточен на переносе этого в браузер, где можно выбрать в основном XSLT, CSS или Javascript. Я предполагаю, что люди, отвечающие за CSS, не те, кто отвечает за Javascripting.
Браузеры плохо справляются с рендерингом XSLT ... это означает, что для правильного рендеринга в браузере вам необходимо рендерить его на сервере, что сводит на нет все преимущества, которые вы имели от его использования. в первую очередь.
Это означает, что вы в конечном итоге выполняете два преобразования на стороне сервера вместо одного: данные -> XML -> HTML вместо данных -> HTML.
XSLT была одной из немногих XML-технологий, которые мне действительно нравились. Концепция XSLT, основанная на наборах и способная работать со всеми видами выходных форматов (не только html), особенно для генерации отчетов, заслуживает того, чтобы ее использовали чаще, чем сегодня.
Я лично никогда ее не использовал. потому что в то время один из браузеров (я полагаю, IE7) не поддерживал рендеринг XSLT в браузере, и у нас не было возможности обработки XSLT на стороне сервера.
Вторая причина в том, что, хотя он отлично подходит для отчетов и представление данных было непрактичным с точки зрения использования общего назначения.
Люди, которые не жили под камнем в течение последних десяти лет, больше не копируют и не вставляют код заголовка и не используют PHP для верстки. Они отделяют представление от реального кода и используют системы шаблонов (например, Smarty, популярный для PHP) синтаксис, который легче понять и рассуждать, чем XSLT.