XSLT на стороне клиента

Question

Я преобразовал весь свой сайт в XML / XSL и хотел бы знать все текущие проблемы с выполнением XSLT на стороне клиента.

Вот те, о которых я уже знаю (из личного опыта):

• Кросс-доменные XSL-файлы (это проблема безопасности, а не кросс-браузер)
• отключение-вывод-экранирование (это не работает в FF ... они считают это проблемой безопасности)

Кроме того, что касается поддержки браузера, это все, что я знаю:

• Опера 9 +
• FF 1.0 +
• SF 2.0 + (я могу ошибаться)
• Chrome
• IE 6.0 +

Любые другие тоже будут полезны:)

Edit:

Что касается 2-й ловушки, то есть достойный обходной путь, который позволяет передавать xhtml в ваш xsl. Он работает путем фактического преобразования и проверки того, что ваш XHTML является допустимым XML, и размещения его в XML как XML. Затем в свой XSL вы копируете xml;) и выводите его как XHTML.

Answer 1

• Скорость: Браузер должен применить XSLT-преобразование перед рендерингом HTML, поэтому пользователю придется ждать дольше, чтобы увидеть страницу. Механизмы XSLT, используемые браузерами, могут быть не первоклассными. В Mac OS X браузер может зависнуть при преобразовании XML и вызвать курсор «вращающийся шарик», таким образом, пользователь может ударить по экрану и травмировать себя.

• Доступность: А как насчет браузеров, не входящих в этот набор, таких как программы чтения с экрана? Эти пользователи важны для вас?

Answer 2

С точки зрения производительности ... учтите, что большинство клиентов в наши дни имеют по 2 ЦП и 2 ГБ ОЗУ каждый, и что большинство серверов не имеют ... По два ЦП + 2 ГБ на каждого клиента. Поэтому, безусловно, логично, что выгрузка XSLT-преобразований должна улучшить масштабируемость, а кэширование CSS + XSLT + JS должно уменьшить общий трафик.

Сказав, что в прошлом я пытался использовать XSLT для создания XHTML, содержащего SVG, у меня был эпический сбой. Самая большая страница была просто слишком большой (более 3000 записей в индексе), и IE использует DOM для преобразования XSLT, что приводит к тому, что она начинает разрушаться. Те же самые преобразования, выполненные в xerces-j (на сервере, в том же окне разработки), были примерно в 1000 раз быстрее.

Самое время, когда браузер-обезьяны получили программу; -)

Интересная дискуссия. Спасибо, что подняли его.

Приветствия. Кит.

Answer 3

Я обнаружил, что параметры передачи в xsltfiles трудно поддерживать перекрестную обработку. Теперь я поддерживаю FF и IE, но из-за этого выпал Chrome ..

Answer 4

Я проработал около года в проекте, где мы использовали xslt + xml-> html (хотя только на стороне сервера)

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

расслоение между xslt / xml / urls становится более сложным, чем должно быть. Вы не можете программировать компонентно-ориентированные.

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

Я бы видел это как форму ранней оптимизации. вы должны начать с использования «нормальной» веб-среды, такой как wicket, jsf, tapestry, gwt и т. д., позже, если выяснится, что производительность вашего сервера связана с процессором, вы можете переписать наиболее часто используемые части приложения таким образом.

otoh, у него есть реальная выгода, если вам нужно предоставить как xml api + html интерфейс.

Answer 5

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

Кроме того, в зависимости от сложности и избыточности данных, вы можете загружать гораздо больше, чем вам действительно нужно - т.е. если HTML уже отображен.