Comments 28
UFO just landed and posted this here
хотелось бы да, увидеть работающий пример
Ммм, то есть кривоватйы велосипед+кэш это новое решение? :)
Ну а что не так?
Ajax — это, по сути, асинхронный метод доставки данных. Сравнивать ваш велосипед с аяксом невозможно просто потому, что в браузере есть единственный адекватный способ выполнения асинхронных запросов — XMLHttpRequest. Если вы его используете — вы уже используете аякс в чистом виде. Причем обновление частей или не частей — это уже не задача аякса по сути. Так как в данных может быть что угодно, кроме того необязательно обновлять что-либо тут же, можно складировать до поры до времени. Потому аякс всего лишь метод получения данных асинхронными запросами. Ключевой момент — это клиентский метод. В вашем случае вы предлагаете серверный костыль, плюс непонятный парсер чего-то и хранилище. Почему бы просто не привязать хранилище к «текущему» аяксу и не мучаться?
Итого, у вас синхронный запрос с кешированием плюс лишний код на сервере, плюс завязка на куки, которые могут быть и вырублены. Плюс в серверном коде в чистом виде лежит html код, что в большинстве случаев просто неприемлемо. Очень смахивает на любимую штуку в ASP — __VIEWDATA, скрытый элемент с килобайтами мусора внутри.
И это вы называете заменой аяксу? Вполне реально добавить тоже клиентское кеширование и спокойно использовать аякс. И не нужно выдумывать велосипедов. Новизны никакой, плюс ко всему, как уже верно заметили, для кеширования есть правильные серверные решения вроде nginx-а.
Ajax же как инструмент отлично справляется со своими задачами, а вот как его используют это уже другое дело. Молоток не виноват, что им забивают шурупы. Правильно используйте инструменты и не будет потребности в костылях.
Ajax — это, по сути, асинхронный метод доставки данных. Сравнивать ваш велосипед с аяксом невозможно просто потому, что в браузере есть единственный адекватный способ выполнения асинхронных запросов — XMLHttpRequest. Если вы его используете — вы уже используете аякс в чистом виде. Причем обновление частей или не частей — это уже не задача аякса по сути. Так как в данных может быть что угодно, кроме того необязательно обновлять что-либо тут же, можно складировать до поры до времени. Потому аякс всего лишь метод получения данных асинхронными запросами. Ключевой момент — это клиентский метод. В вашем случае вы предлагаете серверный костыль, плюс непонятный парсер чего-то и хранилище. Почему бы просто не привязать хранилище к «текущему» аяксу и не мучаться?
Итого, у вас синхронный запрос с кешированием плюс лишний код на сервере, плюс завязка на куки, которые могут быть и вырублены. Плюс в серверном коде в чистом виде лежит html код, что в большинстве случаев просто неприемлемо. Очень смахивает на любимую штуку в ASP — __VIEWDATA, скрытый элемент с килобайтами мусора внутри.
И это вы называете заменой аяксу? Вполне реально добавить тоже клиентское кеширование и спокойно использовать аякс. И не нужно выдумывать велосипедов. Новизны никакой, плюс ко всему, как уже верно заметили, для кеширования есть правильные серверные решения вроде nginx-а.
Ajax же как инструмент отлично справляется со своими задачами, а вот как его используют это уже другое дело. Молоток не виноват, что им забивают шурупы. Правильно используйте инструменты и не будет потребности в костылях.
гм, странное решение.
вы будете каждый раз вызывать перегенерацию страницы, исполнение скриптов, рефлов и полный рендер.
быть может надо было просто посмотреть что перед вами живой человек — и догрузить ему только нужный кусок?
он же не робот — ему индексировать не надо…
see: fullajax.ru/
вы будете каждый раз вызывать перегенерацию страницы, исполнение скриптов, рефлов и полный рендер.
быть может надо было просто посмотреть что перед вами живой человек — и догрузить ему только нужный кусок?
он же не робот — ему индексировать не надо…
see: fullajax.ru/
Вопрос скорее в том, что ajax требует конкретной переделки логики приложения, да и не всегда возможно понять кто к тебе стучит, поисковик или человек (поисковики, они же тоже под людей косят).
в вашем случае не требует.
Что у вас при переходе «как-то» определяется набор блоков что надо показать, что я сам при формировании запроса это вам явно укажу.
Вообще ajax это просто механизм(а лучше назвать это средством) по формированию запроса к серверу.
Совершенно обычному, и абсолютно любому запросу
не забывайте это.
Что у вас при переходе «как-то» определяется набор блоков что надо показать, что я сам при формировании запроса это вам явно укажу.
Вообще ajax это просто механизм(а лучше назвать это средством) по формированию запроса к серверу.
Совершенно обычному, и абсолютно любому запросу
не забывайте это.
в вашем случае не требует.
Что у вас при переходе «как-то» определяется набор блоков что надо показать, что я сам при формировании запроса это вам явно укажу.
Если я вас правильно понял (на что я надеюсь) то вы рассматриваете случай, когда средства скрипта на стороне сервера это позволяют сделать быстро (например шаблонизатор позволяет выдрать блок из полного шаблона) или изначально блоки и запросы к серверу организованы так, что я могу получать блоки по отдельности. Если же мы имеем старую (ну или относительно старую) CMS, которая такими возможностями не обладает, то добавление в неё загрузи блоков страницы по AJAX зачастую оборачивается проблемами.
Вообще ajax это просто механизм(а лучше назвать это средством) по формированию запроса к серверу.
Совершенно обычному, и абсолютно любому запросу
не забывайте это.
Я и не говорю о замене ajax. Понятно, что мой пример не в коем случае не заменит его, например, для посылки фоновых запросов.
Что у вас при переходе «как-то» определяется набор блоков что надо показать, что я сам при формировании запроса это вам явно укажу.
Если я вас правильно понял (на что я надеюсь) то вы рассматриваете случай, когда средства скрипта на стороне сервера это позволяют сделать быстро (например шаблонизатор позволяет выдрать блок из полного шаблона) или изначально блоки и запросы к серверу организованы так, что я могу получать блоки по отдельности. Если же мы имеем старую (ну или относительно старую) CMS, которая такими возможностями не обладает, то добавление в неё загрузи блоков страницы по AJAX зачастую оборачивается проблемами.
Вообще ajax это просто механизм(а лучше назвать это средством) по формированию запроса к серверу.
Совершенно обычному, и абсолютно любому запросу
не забывайте это.
Я и не говорю о замене ajax. Понятно, что мой пример не в коем случае не заменит его, например, для посылки фоновых запросов.
Если я открыл вторую страницу через ваш JS(именно что JS)
то я получил с сервера только часть данных, остальные добил сам из стораджа…
полностью обновив страницу…
Почему нельзя по тем же самым механизмам получить только часть данных, и только часть данных тут же обновить.
По хорошему можно запросить с сервера даже тотже самый урл что и в первом варианте.
Но без обновления страницы(!)
Моя сегодняшняя параноя именно про рефреш
то я получил с сервера только часть данных, остальные добил сам из стораджа…
полностью обновив страницу…
Почему нельзя по тем же самым механизмам получить только часть данных, и только часть данных тут же обновить.
По хорошему можно запросить с сервера даже тотже самый урл что и в первом варианте.
Но без обновления страницы(!)
Моя сегодняшняя параноя именно про рефреш
Вообще, можно совместить предложенный метод с классическим получением блоков по ajax. Такая бы система была бы более правильной и более гибкой. Тем более могла бы содержать некоторые преимущества, так как в отличии от классической загрузки блоков по ajax этот метод дает нам кеш на кучку закладок сразу. Т.е. загруженный блок в одной закладке автоматически будет кешем для других.
Не понятно, в чём проблема? либа jQuery есть в CDN гугла размером в 25 кб.
На jQuery работа с аяксом примитвна — несколько строк и поддержка браузеров, начиная с ie6+.
Для hi-load проектов связка nginx+memcache прекрасно справляется для кэширования статики и юзер-блоков.
На jQuery работа с аяксом примитвна — несколько строк и поддержка браузеров, начиная с ie6+.
Для hi-load проектов связка nginx+memcache прекрасно справляется для кэширования статики и юзер-блоков.
jQuery, как я уже писал в посте — это всего лишь временное средство достижения результата. Так что к нему изначально можно не привязываться. Тем более, в лучшем случае, использование того же самого CDN как ни крути, но генерирует один (на скрипт) лишний запрос браузера куда-то, пусть даже ему там и отвечают «файл не изменен». По крайней мере на своей машине такие запросы (а точнее ожидание этого коротенького «файл не изменен») зачастую доходит до 50% времени загрузки и обработки всей страницы.
Если же говорить в общем смысле, мне такая идея нравиться тем, что она на современных браузерах дешево стоит, а на старых её можно не исполнять. И… несомненным плюсом является простота, то, что на стороне сервера мне достаточно написать пару строк, а те же JS и CSS просто проинклудить в тело документа, что бы автоматом их кешировать, а так же не заботиться о том, что я генерирую 10 запросов на 1 страницу к своему серверу для получения нужных данных.
Если же говорить в общем смысле, мне такая идея нравиться тем, что она на современных браузерах дешево стоит, а на старых её можно не исполнять. И… несомненным плюсом является простота, то, что на стороне сервера мне достаточно написать пару строк, а те же JS и CSS просто проинклудить в тело документа, что бы автоматом их кешировать, а так же не заботиться о том, что я генерирую 10 запросов на 1 страницу к своему серверу для получения нужных данных.
Сложность переделывать на AJAX? Почитав вашу идею у меня вообще голова закружилась.
Мне кажется, что Local Storage еще хуже поддерживается старыми браузерами, чем аякс.
Ну зато, в случае отсутствия у браузера AJAX, вы не увидите ничего (если заранее не испытали геморрой по поддержке таковых), а в случае отсутствия localStorage бы увидите полноценную страницу. В этом я считаю и есть основной плюс — отсутствие геморроя для затачивания под разные требования со стороны клиента.
Может кто подскажет блог, в который это можно было бы перенести?
P.S. Если вы конечно не считаете это бредом и что его нужно перенести в блог «я мусор»)))
P.S. Если вы конечно не считаете это бредом и что его нужно перенести в блог «я мусор»)))
На самом деле не так много посетителей приходит на сайт с непустым кэшем — в Yahoo! по этому поводу исследование проводили. Что же касается localStorage и AppCache, то там данные тоже могут храниться некоторое время. Так что мне видится, что метод вполне применим для сайтов, которые часто посещаются пользователем, например для соц сетей или online productivity apps. И опять же никто не запрещает использовать его вместе с аяксом.
По мне, так GWT — идеальное решение. А обмена данных — так вообще минимум, и поддерживаются все браузеры чуть ли не начиная с 5 IE
Sign up to leave a comment.
Web 1.5 или частичная замена Ajax