Pull to refresh

Comments 29

Давно не видел такой слабообоснованной критики jQuery…
Я немного подправил формулировку P.S., не очень хочется во всех подробностях обсуждать реализацию на конкретном фреймворке — это дело каждого.
К сожалению, отловить событие document.location.hash onChange невозможно

да неужели?

$(window).bind('hashchange', function () { ... });
Не во всех популярных браузерах, насколько я в курсе.
live и не убирать класс EngineAJAX. не?
Пробовал не убирать EngineAJAX. Получается медленнее «найти все ссылки на страницы и понять проставлены ли им #!», особенно если на странице 100+ ссылок. Поэтому и убираю класс EngineAJAX, чтобы повторно не анализировать уже преобразованные в якоря ссылки.

Насчет live — честно, не понял, что имеете ввиду.
$('a.EngineAJAX').live('click', function() {
console.log(this); // аяксовая ссылка
});
Спасибо, попробую. Хотя не думаю, что это добавит производительности по сравнению с:

document.observe(«click», function(event) {
var e = Event.element(event);
// тут проверка на ajax-ссылку
});
Но и, наверняка, не проиграет. Есть предположение что это синонимы))
UFO just landed and posted this here
live это метод в jQuery, он привязывает обработчик к событию для всех текущих и будущих элементов dom api.jquery.com/live/
На счет live, спасибо, пощупаю.
Правда, я все выше перечисленное реализовал на prototype.
на хабре надо почаще страницы обновлять)
даже без использования jQuery.live, почему бы не добавлять в обработанные ссылки дополнительный атрибут или класс, дабы не обрабатывать якоря повторно?
Я уже про это подумываю.
На самом деле, тут затык в производительности не в этом моменте, а в отлове dom:change и hash:change…
По-моему, проще все ссылки по-умолчанию считать аяксовыми. А при необходимости некоторым ссылкам добавлять какой-нибудь класс, который позволит не обрабатывать их. Примерно как на zaycev.fm.
Мне кажется, что это больше зависит от проекта. Если аяксовых ссылок больше — то можно считать все ссылки аяксовыми по умолчанию.
.delegate() — самое то. C .live() есть проблемы (с контекстом). onHashChanged тут какбе и не надо — один раз заменить ссылки, а потом заменять перед вставкой контента. Тогда через .delegate() мы будем ловить клики, а вот onHashChange() уже и не понадобится.
onHashChange нужен для того, чтобы можно было отправить ссылку другу и понять что нажата кнопка «назад» в браузере.
Мне кажется лучше с другой стороны вообще пойти.
Например jQuery.Address</a?

+
Google

Ну с другими поисковиками конечно прийдется смирится. Хотя может быть есть что-то для Яндекса/Рамблера.
Рекомендую чаще (а не то и вообще всегда) пользоваться кнопкою «предпросмотр», да притом не на одном только Хабрахабре, но и на всяком таком сайте, на котором предпросмотр есть, а вот зато редактирование комментариев отсутствует совершенно.
Разработчики Fullajax уже несколько лет назад решили эти проблемы. И те, до которых вы ещё не дошли.
Насчет проверки изменения хэша (в т.ч. и дабы решить проблему с историей) — один из авторов jQuery написал свой плагин (и не один):
benalman.com/projects/jquery-hashchange-plugin/

Для браузеров, не поддерживающих стандартное событие onhashchange там таки вечный цикл с проверкой.
Всегда мучал вопрос: Почему большинство пытается прикрутить параметр типа ?notemplate=1, вместо того, чтобы просто проконтролировать заголовок запроса на наличие и тип X-Requested-With?
Конечно, ?notemplate=1 проще контролировать, но контроль X-Requested-With использует уже готовый механизм. К тому же позволяет понять, в каком формате: XML, JSON, HTML клиет хочет получить ответ.
Каюсь, до сегодняшнего дня я не знал про X-Requested-With. Теперь буду применять именно его.
Правда, сразу вижу проблему: nginx на front-end большинства хостеров может не передать этот заголовок.
Sign up to leave a comment.

Articles