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

Question

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

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

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

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

• Opera 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

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

Answer 3

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

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

Answer 4

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

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

Это высокое время браузерной обезьяна получила с программой ;-)

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

Cheers. Кит.

Answer 5

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

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

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

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

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

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