Преимущества / недостатки использования XSL для рендеринга целых веб-страниц
Я нахожусь на предварительных этапах планирования проекта с клиентом по переделке их текущего веб-сайта. Я взглянул на их текущий сайт, чтобы узнать, с какими проблемами они в настоящее время имеют дело, и после осмотра заметил, что каждая страница отображается полностью с использованием XSLT. Я знаком с XSLT, я использовал его для визуализации настраиваемых элементов управления, которые необходимо часто обновлять на стороне клиента, но никогда для визуализации всей страницы.
Помогите мне стать менее невежественным, что может быть причиной этого? Какие преимущества или недостатки это приносит?
Ответы 7
Похоже, они сделали это, потому что они очень хорошо знали XSL-T и уже имели под рукой XML-данные.
Сам я бы не хотел этого решения. XSL-T - не самая простая вещь для чтения или записи. Он не подходит для визуализации того, как будет выглядеть страница. Это исключает дизайнеров и веб-разработчиков. И это плохо интернационализируется. Нет ничего эквивалентного пакетам ресурсов Java, которые могут извлекать информацию, специфичную для локали. Я не считаю вырезание и вставку хорошим решением.
На стороне сервера:
Advantages:- Чистые, лаконичные шаблоны
- Простой способ преобразовать данные XML в HTML
- Достаточно быстро
- Модель программирования незнакома и неудобна для многих программистов, использующих процедурный язык.
- Неудобно, если некоторые или все исходные данные представляют собой нет в XML
- Может быть очень медленным при неосторожном использовании (небольшие изменения могут иметь большие последствия)
Сторона клиента:
Advantages:- Удобный способ переложить обработку на клиентский код, где сценарии потенциально могут лучше знать, как лучше всего отформатировать полученный HTML.
- Поддержка браузера повсюду.
- Google не благодарит вас.
Не могли бы вы подробнее рассказать о том, "Google не будет вам благодарить"?
@jackdh Я считаю, что он имеет в виду, что Google не будет отдавать предпочтение страницам, созданным с использованием XML / XSLT, в своем поисковом рейтинге. Просто потому, что Google не может правильно отображать эти страницы. stackoverflow.com/questions/7393522/…
XSLT на стороне клиента
- Отключает прогрессивный рендеринг. Пользователь вообще ничего не увидит, пока не будет полностью загружена вся таблица стилей и данные.
- Не поддерживается поисковыми системами и другими сканерами. Они увидят необработанный XML.
- Не поддерживается старыми / менее продвинутыми браузерами.
XSLT в целом
- Если вы тщательно не создадите таблицы стилей, их будет сложно поддерживать:
- с многочисленными шаблонами может быть очень сложно определить, какие шаблоны применяются.
- многословность синтаксиса XSLT и XML затрудняет понимание чего-либо с первого взгляда.
- Уловки XPath заманчивы, но кошмар, чтобы изменить их позже.
Похоже на XML-фетиш "все поют-все-танцуют".
Поскольку с XSLT можно делать что угодно, с таким же успехом можно делать все. У меня были люди, которые спрашивали, почему хранилище данных - это не просто XSLT-преобразования между вводом, витриной данных и отчетами.
Преимущество. Все в XML.
Недостатки.
Не очень читабельно. Шаблоны ваших страниц связаны как преобразования XSLT с запутанными функциями циклов и условной обработки.
Любое изменение шаблонов страниц требует наличия эксперта по XSLT в дополнение к графическому дизайнеру, создавшему (и отлаживающему) HTML и CSS.
Самое большое преимущество: платформенный нейтральный способ рендеринга xml
Самый большой недостаток xsl сложно поддерживать
Однажды мне пришлось работать с xsl длиной более 4000 строк, который также включает несколько других шаблонов xsl. Теперь с этим было тяжело работать!
Я думаю, что XSLT великолепен, если построен правильно (мы используем структуру шаблонов в работе).
Приведенные выше ответы дают хороший обзор некоторых преимуществ и недостатков XSLT. Хочу добавить еще один минус. Мы обнаружили, что вы довольно быстро сталкиваетесь с проблемами масштабируемости при использовании XSLT для умеренно больших наборов данных.
При обработке файлов XML XSLT должен загружать в память весь документ. С Xalan это потребляет примерно в 10 раз больше размера входного файла (у saxon есть альтернативная реализация DOM, которая использует меньше памяти). Если какой-либо из ваших входных наборов данных превысит пару сотен мегабайт, ваш XSLT-процессор может просто выйти из строя.
Чтобы смягчить недостатки на стороне клиента, вы можете обнаружить заголовки пользовательского агента на сервере и при необходимости переключиться на рендеринг на стороне сервера. Таким образом, если на ваш сайт попадет старый браузер, googlebot, msnbot и т. д., Вы сможете преобразовать их в html.