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

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

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

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

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

Opera 9 +
FF 1.0 +
SF 2.0 + (возможно, я ошибаюсь)
Chrome
IE 6.0 +

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

Edit:

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

Ответ 1

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

Ответ 2

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

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

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

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

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

Ответ 3

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

Ответ 4

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

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

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

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

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

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

Ответ 5

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

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