Comments 27
Америки нет. То есть статьей вы её не открыли, но все равно спасибо за информацию. ИМХО: главная страница раздела с AJAX и ссылки через # дописываются к location страницы и версию для слепых отключенного JavaScript. Фрэймворки грузные больно.
Допустим, каталог продукции некоторого интернет-магазина реализован с помощью ajax. Правила хорошего тона требуют наличия постоянной ссылки на конкретный товар (я хочу посоветоваться с кем-то перед совершением покупки). Будет ли вариантом использовать в качестве такой ссылки /items#345 (а именно ее будет копипастить пользователь из адресной строки) или же давать статику /items/345 (сообрази, что надо копировать ссылку из содержимого страницы), но пригодную для индексации поисковиками и пользователям с отключенными скриптами.
я считаю, что в данном случае применимы оба варианта. Только надо задуматься о двух аспектах:
1) ссылка должна быть доступна пользователям и роботам с отключенным JS (т.е. просто по якорю, если якорь используется). В данном случае, если описание товара большое, это может привести в большому размеру результирующей страницы. Соответственно, для больших описаний товаров я бы порекомендовал использовать постоянную ссылку где-либо на видном месте, либо не использовать AJAX
2) ссылка должна быть доступна, если у пользователя включен JS. Т.е. он вводит в адресную строку /items#345, и ему открывается именно то, что он видит, если просто перейдет по ссылкам на сайте. Организовать это можно просто проверяя на некотором моменте значение hash в URL'е и подгружая соответствующий документ.
В общем, нужно знать специфику. Вот тут использован похожий функционал (можно выбирать соответствующие материалы из списка для каждого продукта), только на результирующей странице выпадающий список (select) не меняет URL'а страницы, а так концепция полностью удовлетворяет описанным выше условиям.
1) ссылка должна быть доступна пользователям и роботам с отключенным JS (т.е. просто по якорю, если якорь используется). В данном случае, если описание товара большое, это может привести в большому размеру результирующей страницы. Соответственно, для больших описаний товаров я бы порекомендовал использовать постоянную ссылку где-либо на видном месте, либо не использовать AJAX
2) ссылка должна быть доступна, если у пользователя включен JS. Т.е. он вводит в адресную строку /items#345, и ему открывается именно то, что он видит, если просто перейдет по ссылкам на сайте. Организовать это можно просто проверяя на некотором моменте значение hash в URL'е и подгружая соответствующий документ.
В общем, нужно знать специфику. Вот тут использован похожий функционал (можно выбирать соответствующие материалы из списка для каждого продукта), только на результирующей странице выпадающий список (select) не меняет URL'а страницы, а так концепция полностью удовлетворяет описанным выше условиям.
В конце концов, движение по сайту напоминает скорее дерево, а не список - так и надо показывать дерево, а не позицию в списке; но при использовании AJAX сайт превращается в автомат с памятью и набором состояний - и движение назад реализовать слишком сложно, если вообже возможно, это отход от исходной модели, когда http запросы были вещью в себе.
Советую также посмотреть на специально сделанный для этого контрол в следующей версии ASP.NET - . Целая статья про это - тут
Сорри, ссылку не вставил - http://quickstarts.asp.net/Futures/ajax/doc/history.aspx
Решение с ифреймами не подходит, imho.
Многие опытные пользователи ходят с баннерорезками или режут фреймы.
Стоит ли терять эту аудиторию?
PS Мне очень нравится последняя тенденция на хабре со статьями по программингу :)
Хотелось бы побольше таких статей.
Сейчас ищу хоть какие-то материалы по кешированию и оптимизации работы.
Не подскажите где о таком можно почитать?
Многие опытные пользователи ходят с баннерорезками или режут фреймы.
Стоит ли терять эту аудиторию?
PS Мне очень нравится последняя тенденция на хабре со статьями по программингу :)
Хотелось бы побольше таких статей.
Сейчас ищу хоть какие-то материалы по кешированию и оптимизации работы.
Не подскажите где о таком можно почитать?
знаете, все, что узнал про кеширование в последнее время, узнал из расширение YSlow к Firebug. Специально насчет статей пока не смотрел
хотелось бы про кеширование не только в js.
может просто есть общие методики.
может просто есть общие методики.
там не только в JS, там более-менее комплексно, ETag, заголовки и т.д.
Лучшее что я нашол по кешированию здесь http://xmlhack.ru/texts/06/doing-http-caching-right/doing-http-caching-right.html
Сам пользовался в нескольких приложениях которые вытягивали достаточно большие объ`ёмы данных из открытых источников которые для этого не предназначены, объём трафика уменьшился в разы, да и вероятность быть забаненным изза DDoS уменьшилась.
Сам пользовался в нескольких приложениях которые вытягивали достаточно большие объ`ёмы данных из открытых источников которые для этого не предназначены, объём трафика уменьшился в разы, да и вероятность быть забаненным изза DDoS уменьшилась.
Спасибо. Почерпнул несколько идей для себя.
Скорее всего я не правильно выразился о своих "хотелках".
Почитал бы информацию о правильном проектировании приложения (в моем случае php-скрипты) с возможностью кеширования результатов и оптимизации вычислений.
С кешированием наверное копаться в исходниках современных форумов.
Тут http://www.lixil.ru/engine/turbo/ пишут, что создали новый супер-пупер web 2.0 движок, который хорошо кеширует, и оптимизирован по запросам.
Правда при создании демо-версии для конкретного пользователя весь сервер висит :)))
Скорее всего я не правильно выразился о своих "хотелках".
Почитал бы информацию о правильном проектировании приложения (в моем случае php-скрипты) с возможностью кеширования результатов и оптимизации вычислений.
С кешированием наверное копаться в исходниках современных форумов.
Тут http://www.lixil.ru/engine/turbo/ пишут, что создали новый супер-пупер web 2.0 движок, который хорошо кеширует, и оптимизирован по запросам.
Правда при создании демо-версии для конкретного пользователя весь сервер висит :)))
Ну здесь надо вебдевов просить. Я разработкой по ВЕБ не занимаюсь, просто делал несколько клиентских приложений для личных целей. А насчёт PHP то у меня это больше религиозное, ну идиосинкразия у меня на 99% проэктов на нём написанных да и фрейворки(не только на ПХП) плодятся чуть ли не каждую неделю.
Самое главное в этой статье "я бы советовал вам использовать AJAX только в случаях крайней необходимости" :) Если следовать этому совету то и проблем с беком не возникает.
А ещё стоит написать статью "дайте людям понять что грузится аяксовый запрос, а то они нажали кнопку и ничего не происходит". Пример - коменты на хабре.
А ещё стоит написать статью "дайте людям понять что грузится аяксовый запрос, а то они нажали кнопку и ничего не происходит". Пример - коменты на хабре.
>предоставление информации или обеспечение функциональности
можно подумать, что одно противоречит другому. это же просто два разных аспекта.
спасибо за статью.
можно подумать, что одно противоречит другому. это же просто два разных аспекта.
спасибо за статью.
По поводу Ajax можно смело посмотреть реализацию GMail там все работает как надо и назад и вперед =)
Ссылка на этот сайт неправильная:
>>в частности, это Хабрахабр
>>в частности, это Хабрахабр
UFO just landed and posted this here
статья полезная, спасибо
Статья полезная, спасибо! От себя могу добавить, что подобная технология используется и на гугловском фото-сайте. Например:
http://picasaweb.google.com/lh/searchbrowse?psc=G&filter=1&q=New#5
http://picasaweb.google.com/lh/searchbrowse?psc=G&filter=1&q=New#5
Большое спасибо, очень интересно.
Замечу, что реализовать все это по-настоящему правильно можно только через continuations (кстати, это относится и к кнопкам назад-вперед в обычных многостраничных POST-формах)
Замечу, что реализовать все это по-настоящему правильно можно только через continuations (кстати, это относится и к кнопкам назад-вперед в обычных многостраничных POST-формах)
Sign up to leave a comment.
Практический AJAX: что делать с кнопкой «назад» в браузерах