Клиентский XSLT
Может быть, ниже приведен код, который вы хотели:
<ul>
<li>{{message}}</li>
<li ng-repeat="x in message track by $index">{{x.REZCMD}}</li>
</ul>
5 ответов
Скорость: Браузеру необходимо применить преобразование XSLT перед рендерингом HTML, поэтому пользователю придется дольше ждать, чтобы увидеть страницу. Механизмы XSLT, используемые браузерами, могут быть не первоклассными. В Mac OS X браузер может зависнуть во время преобразования XML и вызвать "вращающийся пляжный мяч" курсор, таким образом, пользователь может ударить по экрану и поранить себя.
Доступность: А браузеры нет. в том наборе, как скринридеры? Имеют ли значение для вас эти пользователи?
Что касается производительности ... учтите, что большинство клиентов в наши дни имеют 2 процессора и 2 ГБ оперативной памяти каждый, а у большинства серверов нет ... Два процессора + 2 ГБ на клиента, то есть. Так что, безусловно, логично, что разгрузка преобразований XSLT должна улучшить масштабируемость, а кеширование CSS + XSLT + JS должно снизить общий трафик.
Сказав, что я пытался использовать XSLT для создания XHTML, содержащего SVG, в прошлое, и у него была эпическая неудача. Самая большая страница была просто слишком большой (3000+ записей в индексе), и IE использует DOM для выполнения XSLT-преобразования, что приводит к тому, что она начинает мусор. Те же преобразования, выполненные в xerces-j (на сервере, в том же самом устройстве), были примерно в 1000 раз быстрее.
Давно пора браузеру-обезьянам с программой; -)
Интересное обсуждение. Спасибо, что подняли его.
Ура. Кит.
I found passing parameters to xsltfiles difficult to keep crossbrowsing able. I now support FF and IE but Chrome fell out because of it..
XSLT-файл - это еще один объект, который необходимо загрузить, и браузер будет получать только 2 или 3 элемента параллельно. Мой опыт показывает, что общая производительность (загрузка и генерация) заметно ниже.
Также, в зависимости от сложности и избыточности данных, вы можете загружать гораздо больше, чем вам действительно нужно, т.е. если HTML уже был обработан.
Я проработал около 1 года над проектом, в котором мы использовали xslt + xml-> html (хотя и только на стороне сервера)
. Главный недостаток, с которым я столкнулся: нет хороших инструментов для xslt, которые склоняются к веб-разработке. нет предварительного просмотра html. нет проверки. полученный xslt был полным беспорядком, которого никто не мог понять. это было не столько ошибкой разработчиков xslt, сколько результатом модели обработки xslt.
распределение слоев между xslt / xml / urls становится более сложным, чем должно быть. Вы не можете программировать компонентно-ориентированные программы.
часто требовалось несколько файлов xslt, что приводило к множеству загрузок на стороне клиента. в противном случае это привело бы к массовому дублированию кода во всем проекте.
Я бы рассматривал это как форму ранней оптимизации. Вы должны начать с использования "обычного" веб-фреймворка, такого как wicket, jsf, tapestry, gwt и т. д., позже, если окажется, что производительность ваших серверов привязана к процессору, вы можете переписать наиболее часто используемые части приложения таким образом.
OTOH,