Pull to refresh

Comments 51

Вперёд назад можно сделать, но изящного решения, увы, нет.
В своих проектах я делаю так: завожу таймер, который через полсекунды проверяет не изменился ли document.location.hash (когда нажали, допустим, «назад»). Если изменился показываю соответствующий контент. В Опере с боками работает, в остальных браузерах — ок.
Хотел даже показать пример реализации, но только что нашёл в нём баг :)
Так что не покажу.
тоже делаю подобное решение, как вы разобрались с тем что IE не записывает в хистори изменения хэша?
проверяю только в ие8. там работает. но я принудительно делаю
document.location.hash=id
может быть. не проверял. я для всех IE делаю обновление хэша в скрытом фрейме.
для этого есть небольшой плагин для jQuery — sammy.js
В чем сермяжная правда гонять на сервер содержимое pageContent?
context:$('#pageContent')

Нет начальной инициализации страницы.
Что будет если придут с букмарки #do/some?
не понял вопросов, если честно
context задает получателя AJAX-событий

>Нет начальной инициализации страницы.
Она не нужна, если первое попадание идет на index page
Есть отличный мини-фреймворк backbone.js, который превосходно реализует хэш-навигацию. Я попробовал и мне очень понравилось, как там организован этот момент.
Скажем, в Gmail можно получить прямую ссылку на письмо, причем ссылка будет bookmarkable

обожаю когда так пишут :)
результат постепенного рефакторинга текста =)
$('a.navlink').each(function() { $(this).click(clickNavLink); });

-->
$('a.navlink').click(clickNavLink);


и почему вы не отслеживаете, если пользователь уже перешел по заанчеренному урлу?
p.s. для jQ есть, кстати, sammy (https://github.com/quirkey/sammy).
спасибо, поправил.
>и почему вы не отслеживаете, если пользователь уже перешел по заанчеренному урлу?
отслеживаю. но не в этой серии )))
Я не знаком с Java. Поэтому не пинайте, но у меня вопрос вы здесь используете Google Web Toolkit? Если нет, то мой другой вопрос отпадает.
Тут используется фреймворк Grails, на языке Groovy.
есть у меня черновик статьи про анкорбайсед навигацию. недавно набросал. но я ее тут не запощу (по вполне определенной причине)

сделаю пару замечаний

>Обновляем состояние ссылок, чтобы отметить активные/неактивные

для этого в jquery есть метод live

если вашу ссылку с якорем просто вставить в адресную строку браузера, то она не сработает. (если правильно понял)
для этого в jquery есть метод live


Не понял, при чем тут он.

если вашу ссылку с якорем просто вставить в адресную строку браузера, то она не сработает. (если правильно понял)

в данном варианте — нет
Статья, если честно, ни о чем… ни одной животрепещущей проблемы в ней освещено не было. Только и того, что сервер приплетен сервер, непонятно зачем, с таким же успехом вместо него можно было использовать просто несколько HTML страничек, в содержательности статья не потеряла бы вообще ничего.

После строки: return document.location.toString().substr(0, document.location.toString().indexOf('#')) + anchor.substr(1); читать вообще расхотелось. Выше по тексту было 2 раза использовано свойство document.location.hash, но при этом был изобретен свой велосипед вместо остальных свойств.

Понятно, что человек осваивает JS+jQuery, но делать из этого цикл статей, вместо того, чтобы использовать уже существующие решения — это сурово. Лично я, рассчитывал увидеть более менее продакшен решение, потому как реально то насущность поставленных вопросов велика, и грамотную реализацию, учитывающую все нюансы — сложно.

Вот еще вопрос по статье: хорошо, а как я могу учесть изменение поведения остальных блоков на изменение одного? Изменение статуса ссылок — это хорошо, но если мне надо радикально поменять меню, в зависимости от того, какой блок был загружен? В блок писать простыни JS, которые бы модифицировали код остальной страницы?
>Только и того, что сервер приплетен сервер, непонятно зачем

Нетрудно заметить, что это блог «Groovy & Grails».

>Лично я, рассчитывал увидеть более менее продакшен решение
Тогда советую вам почитать про GWT.

>Изменение статуса ссылок — это хорошо, но если мне надо радикально поменять меню, в зависимости от того, какой блок был загружен? В блок писать простыни JS, которые бы модифицировали код остальной страницы?

Правильный ответ тут один — IT DEPENDS. Лично я могу дать совет интенсивнее использовать события jQuery.
Так это понятно, что блог «Groovy & Grails». Просто задача то решается на JS, Groovy в данном случае ничем не помогает. То есть если его заменить на PHP, Perl, Pyton etc, в вашем решении ничего не изменится. И что, теперь вашу статью можно с минимальными изменениями скопировать во все остальные блоги ?:)

События событиями… но речь немного не о том. У вас описан один блок на странице. Как будут сохраняться события и история переходов если блоков несколько?
>То есть если его заменить на PHP, Perl, Pyton etc, в вашем решении ничего не изменится.

Изменится. См. часть 2

>Как будут сохраняться события и история переходов если блоков несколько?

Все определяется структурой URL. Как правило, либо блоки независимы — тогда клики независимы, либо вложены друг в друга — тогда ссылки внутри блока должны содержать нужное состояние. Это если рассуждать об сферических конях в вакууме.
Что значит клики независимы? То есть если я кликнул в одном блоке — изменил его содержимое, кликнул в другом — тоже изменил, потом кинул ссылку другу, в надежде что он увидит первый блок в измененном состоянии — я обломаюсь? Или мне надо делать аналоги Jquery-евских addClass removeClass для hash-а, которые будут вставлять состояния всех блоков в URL?
Надо либо передавать состояние через javascript, либо загружать сразу оба блока через AJAX — опять же мне сложно обсуждать абстрактную ситуацию. Сохранять ВСЕ возможные события в странице через состояние URL особо никому не нужно.
Вот как раз сохранять все события на странице то и нужно, хотя бы для того чтобы хистори и кнопка Back работала.

А если мыслить категориями одной страницы (одного блока) — то AJAX не нужен. CSS и JS отлично кешируется броузером, за-gzip-ленный контент на современных каналах прокачивается практически моментально. То есть все эти ухищрения с урлами, таймерами, аяксом и дополнительными обработчиками на стороне сервера только для WOW-эффекта не окупают себя никак. А если мы уходим от одноблочной структуры — то все, финиш, вся проработка сохранения статусов страницы опять ложится на плечи разработчика, и вместо разработки бизнес-логики он будет писать костыли для расширения вашего или другого такого же модуля.

То есть, такие модули должны работать как минимум с 2-мы блоками, чтобы их потом можно было по индукции расширять до любого n. В этом случае, да, профит будет очень высоким.
Я не совсем понял, что такое модуль. Ну да ладно.

CSS и Javascript загружаются далеко не моментально, они требуют инициализации и часто блокируют другие действия во время загрузки, так что игра с оптимизацией стоит свеч.

Я не думаю, что тут есть универсальное решение на все случаи жизни. Реальные приложения сильно разные, вряд ли тут есть волшебный рецепт.

Если действительно интересуют всеобъемлющие решения такого рода, советую посмотреть компонентные фреймворки типа GWT, Wicket, ThinWire. Хотя, честно говоря, не верю, что они сами смогут написать за разработчика весь.
CSS грузится один раз. А говорить о длительности инициализации JS-а (которого на сайте без AJAX-а может быть не так много), при том, что выставляется полусекундная задержка при каждом переходе со страницы на страницу — это как то странно.

По поводу универсальности: а универсального решения не надо. Потому как чем универсальнее решение, тем больше сил на его конфигурацию и настройку тратишь. Те же ThinWire, GWT и прочие с ними — это вообще нечто. Писать на Java Javascript — это только отличная возможность получить неподдерживаемый код, а не решение. А хотелось бы чего то достаточно простого и маленького, но в котором наиболее общие случаи работы со страницой шли бы из коробки, а экзотику надо было бы писать уже самостоятельно.

А у вас, к сожалению, вся изюминка обоих статей уложилась в использование анализа HTTP заголовков для определения, какой шаблон надо выдать. В итоге, если вы хотели донести эту идею до читателей, достаточно было бы просто взять и написать пример ее использования именно в Grails, JS часть попросту убрав в файлик и оставив в статье только ссылку на скачивание, либо вообще построив пример на какой нибудь уже известной библиотеке.
>выставляется полусекундная задержка при каждом переходе со страницы на страницу

Вы вообще текст-то читали? Полсекундная задержка возникает при переходе back/forward.

>Писать на Java Javascript — это только отличная возможность получить неподдерживаемый код, а не решение.

Это неверно. Javascript ничем не хуже Ruby или Python.

>CSS грузится один раз. А говорить о длительности инициализации JS-а (которого на сайте без AJAX-а может быть не так много), при том, что выставляется полусекундная задержка при каждом переходе со страницы на страницу — это как то странно.

Должен разочаровать, но крупные компании уделяют этому столько внимания, что тема неполной загрузки страницы весьма актуальна. Посмотрите, например, YUI.

>достаточно было бы просто взять и написать пример ее использования именно в Grails, JS часть попросту убрав в файлик

Договорились — в следующий раз обязательно проконсультируюсь у вас, как и про что мне писать! =))))
Дело не в том, что Javascript хуже питона или руби. А в том, что в вышеперечисленных вами решениях надо писать код на Java, который потом уже транслируется в Javascript. То есть — если нет исходников на Java, то есть большие проблемы.

Насчет полусекунды — да, погорячился, но на статичных (то есть без JS в большом количестве) сайтах, коих большинство — инциализировать вообще нечего.

>Должен разочаровать, но крупные компании уделяют этому столько внимания, что тема неполной загрузки страницы весьма актуальна.
Я не разочаровываюсь… отнюдь. Я сам плотно занимаюсь данным вопросом, и то, что я к вам прицепился — означает лишь то, что мне эта тема небезралична, и посему от вашей серии статей ждал нечто большего :) Поэтому и пытаю в комментах, в надежде на уточнения и дополнения. ;)

>Договорились — в следующий раз обязательно проконсультируюсь у вас, как и про что мне писать! =))))
Согласен :)

> Изменится. См. часть 2

Во второй части специфики grails-овой не обнаружено. Или вы считаете, что умение отловить X-HTTP-Requested-With спецификой только грельсов?
так в чем вопрос-то? можно ли скопировать этот JS-код в другие блоги? или вы хотите прорекламировать какую-то существующую библиотеку?
Вопрос в том, что вы говорите, что во второй части есть какая-то grails-специфика, я её там не обнаружил. О чем и сообщил, в надежде, что вы её укажете более явно.
специфика в интеграции того и другого, думаю, она интересна разработчикам на grails, или вы ждете каких-то откровений?
>Только и того, что сервер приплетен сервер, непонятно зачем

Нетрудно заметить, что это блог «Groovy & Grails».

>Лично я, рассчитывал увидеть более менее продакшен решение
Тогда советую вам почитать про GWT.

>Изменение статуса ссылок — это хорошо, но если мне надо радикально поменять меню, в зависимости от того, какой блок был загружен? В блок писать простыни JS, которые бы модифицировали код остальной страницы?

Правильный ответ тут один — IT DEPENDS. Лично я могу дать совет интенсивнее использовать события jQuery.
Я вот только одного не понял: зачем вам анхоры? Ведь всё равно хождение по ссылкам вы перехватываете js-ом, почему не делать ajax по урлу, куда укзывает ссылка? Так во-всяком случае сохранится какая-то функциональность, если js-а нет.
А вот в анхор уже писать то куда пошли.
>Так во-всяком случае сохранится какая-то функциональность
Не сохранится. Без JS вообще работать не будет, т.к. якоря будут недоступны

>Ведь всё равно хождение по ссылкам вы перехватываете js-ом, почему не делать ajax по урлу, куда укзывает ссылка?
Так многие и делают, но при этом возникает задержка, которая мне очень не нравится. См. Одноклассники.
> Не сохранится. Без JS вообще работать не будет, т.к. якоря будут недоступны

Вы невнимательно прочитали. Сохранится, если будет без анхоров.

> Так многие и делают, но при этом возникает задержка, которая мне очень не нравится. См. Одноклассники.

Задержка из-за того, что вы вместо $(this).attr('link').split(''...')… будете $(this).attr('link') в ajax-вызов передавать? Не находите, что это немного неверно?
мы похоже о разных вещах говорим
я говорю о задержке в 500 мс при изменении якоря

>Сохранится, если будет без анхоров.
тогда она не попадет в history
Опять невнимательно читаете, в анхор пишем после перехода по ссылке.
я правильно понял, что все это делается ради того, чтобы все заработало без JS? тогда согласен, что это имеет смысл.
веб-страницы часто загружают просто гигантские CSS и Javascript-файлы, которые при AJAX-обновлении можно повторно не загружать.


Вообще-то, при обычном обновлении, CSS и Javascript тоже повторно не загружаются.
Есть еще инициализация Javascript-кода, в случае jQuery это серьезный кусок кода. Более того, загрузка Javascript иногда блокирует загрузку частей страницы и картинок. Причин лечить ситуацию предостаточно.
Не спорю. Однако, ваше первое утверждение от этого корректнее не становится — там ясно написано: «файлы».
Загрузка файла это не только скачивание. Поэтому утверждение корректное.
Давно есть плагин для jquery, в котором можно подписыватся на события и т.п. Работает везде.

Делал с помощью него ajax-навигацию на этом проекте tanyao.ru/ru/

Sign up to leave a comment.

Articles

Change theme settings