Hash-навигация в AJAX-сайтах

[Mithgol]

Давно не видел такой слабообоснованной критики jQuery…

[maxwp]

Я немного подправил формулировку P.S., не очень хочется во всех подробностях обсуждать реализацию на конкретном фреймворке — это дело каждого.

[farafontov]

К сожалению, отловить событие document.location.hash onChange невозможно

да неужели?

$(window).bind('hashchange', function () { ... });

[myem]

Не во всех популярных браузерах, насколько я в курсе.

[lacki]

live и не убирать класс EngineAJAX. не?

[maxwp]

Пробовал не убирать EngineAJAX. Получается медленнее «найти все ссылки на страницы и понять проставлены ли им #!», особенно если на странице 100+ ссылок. Поэтому и убираю класс EngineAJAX, чтобы повторно не анализировать уже преобразованные в якоря ссылки.

Насчет live — честно, не понял, что имеете ввиду.

[lacki]

$('a.EngineAJAX').live('click', function() {
console.log(this); // аяксовая ссылка
});


[maxwp]

Спасибо, попробую. Хотя не думаю, что это добавит производительности по сравнению с:

document.observe(«click», function(event) {
var e = Event.element(event);
// тут проверка на ajax-ссылку
});

[lacki]

Но и, наверняка, не проиграет. Есть предположение что это синонимы))

[Agent_J]

live это метод в jQuery, он привязывает обработчик к событию для всех текущих и будущих элементов dom api.jquery.com/live/

[maxwp]

На счет live, спасибо, пощупаю.
Правда, я все выше перечисленное реализовал на prototype.

[p00h]

.live()

[p00h]

на хабре надо почаще страницы обновлять)

[Agent_J]

даже без использования jQuery.live, почему бы не добавлять в обработанные ссылки дополнительный атрибут или класс, дабы не обрабатывать якоря повторно?

[maxwp]

Я уже про это подумываю.
На самом деле, тут затык в производительности не в этом моменте, а в отлове dom:change и hash:change…

[Arion]

мне нравиться как все ваши проблемы решили на GitHub, описание можете посмотреть здесь railscasts.com/episodes/246-ajax-history-state с помощью функции pushState

[Nc_Soft]

.delegate() и onHashChanged

[ZaiSL]

По-моему, проще все ссылки по-умолчанию считать аяксовыми. А при необходимости некоторым ссылкам добавлять какой-нибудь класс, который позволит не обрабатывать их. Примерно как на zaycev.fm.

[maxwp]

Мне кажется, что это больше зависит от проекта. Если аяксовых ссылок больше — то можно считать все ссылки аяксовыми по умолчанию.

[pro100tak]

.delegate() — самое то. C .live() есть проблемы (с контекстом). onHashChanged тут какбе и не надо — один раз заменить ссылки, а потом заменять перед вставкой контента. Тогда через .delegate() мы будем ловить клики, а вот onHashChange() уже и не понадобится.

[maxwp]

onHashChange нужен для того, чтобы можно было отправить ссылку другу и понять что нажата кнопка «назад» в браузере.

[josser]

Мне кажется лучше с другой стороны вообще пойти.
Например jQuery.Address</a?

+ Google

Ну с другими поисковиками конечно прийдется смирится. Хотя может быть есть что-то для Яндекса/Рамблера.

[josser]

Парсер — упырь

[Mithgol]

Рекомендую чаще (а не то и вообще всегда) пользоваться кнопкою «предпросмотр», да притом не на одном только Хабрахабре, но и на всяком таком сайте, на котором предпросмотр есть, а вот зато редактирование комментариев отсутствует совершенно.

[Veterinar]

Разработчики Fullajax уже несколько лет назад решили эти проблемы. И те, до которых вы ещё не дошли.

[myem]

Насчет проверки изменения хэша (в т.ч. и дабы решить проблему с историей) — один из авторов jQuery написал свой плагин (и не один):
benalman.com/projects/jquery-hashchange-plugin/

Для браузеров, не поддерживающих стандартное событие onhashchange там таки вечный цикл с проверкой.

[keltanas]

Всегда мучал вопрос: Почему большинство пытается прикрутить параметр типа ?notemplate=1, вместо того, чтобы просто проконтролировать заголовок запроса на наличие и тип X-Requested-With?
Конечно, ?notemplate=1 проще контролировать, но контроль X-Requested-With использует уже готовый механизм. К тому же позволяет понять, в каком формате: XML, JSON, HTML клиет хочет получить ответ.

[maxwp]

Каюсь, до сегодняшнего дня я не знал про X-Requested-With. Теперь буду применять именно его.
Правда, сразу вижу проблему: nginx на front-end большинства хостеров может не передать этот заголовок.