Comments 40
А чем вызвана необходимость проведения преобразований именно на стороне клиента? Или это синтетический пример?
Просто интересуюсь =)
Просто интересуюсь =)
Разгрузка сервера. Клиентские мощности позволяют.
Разгрузка сервера — спору нет.
А вот «Клиентские мощности позволяют» — тут все будет зависеть от объема данных, специфики и сложности структуры, особенно в связи с популярностью нетбуков и прочих мобильных устройств.
Впрочем возможно я несколько субъективен в силу того, что сам никогда трансформации на клиента не переносил.
А вот «Клиентские мощности позволяют» — тут все будет зависеть от объема данных, специфики и сложности структуры, особенно в связи с популярностью нетбуков и прочих мобильных устройств.
Впрочем возможно я несколько субъективен в силу того, что сам никогда трансформации на клиента не переносил.
Реальный пример. Имеем список пользователей. Их можно просматривать и править.
В обычной версии это выглядело бы так. Список пользователей (1 запрос). Кликаем на пользователя — грузится страница с инфой об пользователе (1 запрос на список юзеров + 1 запрос на данные юзера), кликаем изменить — грузится страница с формой редактирования (1 запрос на список юзеров + 1 запрос на данные юзера). Итого 5 запросов.
В случае xml/xsl. Имеем список пользователей (1 запрос). По клику на пользователя подгружаются данные пользователя в xml (1 запрос) и трансформация для представления этих данных в xsl. Кликаем на изменить — подгружается только xsl, содержашая инфу о форме редактирования. А xml с данными он уже загружен и его повторно грузить не надо. Подгружаемые xsl будут закешированы браузером. Итого 2 запроса.
Не всегда, но иногда так даже проще реализовать функционал.
В обычной версии это выглядело бы так. Список пользователей (1 запрос). Кликаем на пользователя — грузится страница с инфой об пользователе (1 запрос на список юзеров + 1 запрос на данные юзера), кликаем изменить — грузится страница с формой редактирования (1 запрос на список юзеров + 1 запрос на данные юзера). Итого 5 запросов.
В случае xml/xsl. Имеем список пользователей (1 запрос). По клику на пользователя подгружаются данные пользователя в xml (1 запрос) и трансформация для представления этих данных в xsl. Кликаем на изменить — подгружается только xsl, содержашая инфу о форме редактирования. А xml с данными он уже загружен и его повторно грузить не надо. Подгружаемые xsl будут закешированы браузером. Итого 2 запроса.
Не всегда, но иногда так даже проще реализовать функционал.
Резонно, спасибо за полезную статью =)
А еще можно для редактирования/валидации/сохранения разные моды использовать. Тогда xsl один только раз нужно будет загрузить. И данные можно сразу префетчить по всем пользователям (если массовое редактирование, например, планируется), если, конечно, сервер считает, что текущий пользователь их может просматривать.
Пока данные лежали на стороне клиента, они обновились на стороне сервера. Ведь доступ к данным может быть для более чем одного пользователя. И ваша суперстройная система рушится, потому что при сохранении вы запишите старые данные. А чтобы это не случилось, придется наворотить непростой механизм валидации данных. Так что не факт, что вы выиграете в итоге.
Не нужно никакой логики на сервере. Т.е. вообще серверная часть сводится к запуску httpd
Пример (у нас так документация устроена): документы (XML) лежат под системой контроля версий. И XSL документы лежат тоже там. Нужно добавить новый документ — берешь шаблон (ссылки на XSL файлы в нем есть), забиваешь данными и кидаешь под версионинг. При просмотре через веб (либо локально по файловым урл-ам) открывается не XML, а его преобразованый в HTML вид. С другой стороны, эти же самые данные могут поступать на вход компьютеризированной системы. Соотвественно: теже файлы по тем же урл-ам скачиваются как просто XML-документы, но никуда не преобразуются, а обрабатываются скриптами.
Пример (у нас так документация устроена): документы (XML) лежат под системой контроля версий. И XSL документы лежат тоже там. Нужно добавить новый документ — берешь шаблон (ссылки на XSL файлы в нем есть), забиваешь данными и кидаешь под версионинг. При просмотре через веб (либо локально по файловым урл-ам) открывается не XML, а его преобразованый в HTML вид. С другой стороны, эти же самые данные могут поступать на вход компьютеризированной системы. Соотвественно: теже файлы по тем же урл-ам скачиваются как просто XML-документы, но никуда не преобразуются, а обрабатываются скриптами.
AJAX-ом. Если на сервере используется XSLT, удобно будет использовать одни и те же шаблоны для вывода чего-нибудь сервером, а потом для динамической подгрузки AJAX-ом.
Про разгрузку ничего говорить не буду, это довольно странно разгружать сервер за счет пользователя, лучше уж пусть сервер потупит, чем потом драгоценного пользователя мучить.
Про разгрузку ничего говорить не буду, это довольно странно разгружать сервер за счет пользователя, лучше уж пусть сервер потупит, чем потом драгоценного пользователя мучить.
Не надо никого мучить. XSLT-преобразования в браузерах работают быстро. И не надо придумывать дополнительных шаблонизацый в виде smarty на javascript'е (во это точно будет работать медленнее).
Даже на страницах в пару мегабайт?
Автору респект!
1) инклудинг;
не надо делать инклудинг — надо собирать все шаблоны в 1-2 файла и отдавать скопом
2) кеширование;
опять же, не надо изобретать велосипеды. нужна нормальная общая система тэгирования подключаемых ресурсов (прописывание версии картинок/стилей/скриптов/шаблонов)
2) проблема обработки инструкции disable-output-escaping=«yes» в firefox.
а нафиг она?
не надо делать инклудинг — надо собирать все шаблоны в 1-2 файла и отдавать скопом
2) кеширование;
опять же, не надо изобретать велосипеды. нужна нормальная общая система тэгирования подключаемых ресурсов (прописывание версии картинок/стилей/скриптов/шаблонов)
2) проблема обработки инструкции disable-output-escaping=«yes» в firefox.
а нафиг она?
1) считаю это мнение ошибочным. Работа с шаблонами на стороне клиента не должна отличаться от такой же работы на стороне сервера. Другими словами — на стороне сервере ник-то же не собирает все шаблоны в один?
2) Шаблоны — да должны кешированться браузером. Я уже описал, когда такое поведение браузера является вредным. Данные же наоборот — в большинстве случаев не должны кешироваться, за некоторыми исключениями.
3) проблема просто существует в этом браузере. А решить её нужно для того, чтобы пользователь получал то, что ожидает увидеть.
2) Шаблоны — да должны кешированться браузером. Я уже описал, когда такое поведение браузера является вредным. Данные же наоборот — в большинстве случаев не должны кешироваться, за некоторыми исключениями.
3) проблема просто существует в этом браузере. А решить её нужно для того, чтобы пользователь получал то, что ожидает увидеть.
1. собирают. и скрипты собирают. даже файловую систему дёргать лишний раз накладно, что уж говорить про удалённые сервера
2. ты не умеешь его готовить просто ;-) habrahabr.ru/blogs/client_side_optimization/90481/
3. xss уязвимость? х)
2. ты не умеешь его готовить просто ;-) habrahabr.ru/blogs/client_side_optimization/90481/
3. xss уязвимость? х)
1) пожалуйста пример какой-либо такой системы (cms, фреймвокр или что-нибудь)
2) спасибо за ссылку
3) уязвимости нет.
2) спасибо за ссылку
3) уязвимости нет.
1. dklab.ru/chicken/nablas/49.html
3. докажи
3. докажи
А насколько xslt+xml производительнее js-шаблонизатора+json? И вообще, как вы считаете, что оптимальнее?
Цифрами доказать не могу, но считаю, что xslt будет работать быстрее. Потому что для обработки шаблона xslt будет использоваться сам шаблон + xslt-процессор браузера. Для обработки js-шаблона потребуются: сам шаблон + js-код + интерпритатор js-кода. А интерпритаторы всегда работают медленнее, чем нормальный скомпиленный код.
Цифрами уже все посчитано.
На последнем я субботнике Степан Резников читал доклад Шаблонизация на клиенте, в котором в конце приведены цифры, так вот js-шаблонизация( в частности Micro-Templating от John Resig) работает быстрее XSLT.
И еще один плюс, на мной взгляд, js-шаблонизации более простой способ хранения темплейтов.
На последнем я субботнике Степан Резников читал доклад Шаблонизация на клиенте, в котором в конце приведены цифры, так вот js-шаблонизация( в частности Micro-Templating от John Resig) работает быстрее XSLT.
И еще один плюс, на мной взгляд, js-шаблонизации более простой способ хранения темплейтов.
Действительно, какой смысл использовать xslt, если нет выигрыша в производительности? Кроме того, нативный яваскрипт в шаблонах куда понятнее и удобнее, чем синтаксис xslt шаблонов.
В случае с js-темплейтом мы вместо одного шаблона имеем два. И если вносятся изменения в один шаблон, то надо править и другой.
На счёт понятности — дело привычки. Если достоточно поработать с xslt, то понимаешь всё его удобство и все его возможности по стравнению с «обычными» шаблонами.
На счёт понятности — дело привычки. Если достоточно поработать с xslt, то понимаешь всё его удобство и все его возможности по стравнению с «обычными» шаблонами.
О каких двух шаблонах идет речь? К примеру шаблон Micro-Templating:
все просто и понятно, и никакого второго шаблона ему не надо.
Мое имхо, json + шаблон с нативным синтаксисом, это удобнее, чем xml + xslt.
>> Если достоточно поработать с xslt, то понимаешь всё его удобство и все его возможности по стравнению с «обычными» шаблонами.
А в чем заключается эти удобство и возможности?
<% for ( var i = 0; i < users.length; i++ ) { %>
<li><a href="<%=users[i].url%>"><%=users[i].name%></a></li>
<% } %>
все просто и понятно, и никакого второго шаблона ему не надо.
Мое имхо, json + шаблон с нативным синтаксисом, это удобнее, чем xml + xslt.
>> Если достоточно поработать с xslt, то понимаешь всё его удобство и все его возможности по стравнению с «обычными» шаблонами.
А в чем заключается эти удобство и возможности?
Очень интересно как к построенным по такому принципу сайтам относятся поисковики? Насколько я себе представляю поисковые боты не умеют производить xslt-трансформацию. Проиндексирует ли сайт поисковик? Что попадет в кеш поисковика?
Sign up to leave a comment.
Решение проблем обработки XSLT на стороне клиента