Передовой опыт: как обеспечить параллельную навигацию браузера и веб-сайта

Это хорошо известная проблема каждому веб-разработчику. Насколько я пытался найти хорошее решение этой проблемы - не нашел (по крайней мере не нашел).

Допустим следующее:

Пользователь ведет себя не так, как ожидалось. Фактический проект, над которым я работаю, использует навигацию внутри веб-портала. Но если пользователь использует кнопку «Назад» в браузере, все становится под угрозой[?], и результат не всегда предсказуем.

Мы использовали инфраструктуру struts и сохранили обратный URL-адрес в формах — в некоторых местах, где нам нужен обратный URL-адрес, он был создан из обратного URL-адреса этой формы. Поскольку для этой информации было только одно поле, и поэтому было невозможно вернуться на несколько шагов назад.

При изменении struts-flow (что может привести к использованию другой формы) эта информация будет потеряна.

Если пользователь посмеет поставить закладку где-нибудь в вашем веб-приложении, возможно, эта информация никогда не была установлена, и снова результат будет либо непредсказуемым, либо недостаточно гибким!

Мое решение:

Я сохранял каждую страницу, связанную с навигацией, которую посещал пользователь, в хранилище наподобие стека в сеанс. Это означает, что путь навигации собирается и сохраняется для последующих переходов.

На любой странице в веб-приложении, где задействована обратная навигация, я использовал самодельный тег, который отображает содержимое стека в URL-адрес.

И все. При щелчке по этому обратному URL-адресу стек заполняется содержимым обратного URL-адреса, по которому щелкнул пользователь (который содержит всю информацию из стека после отображения обратной ссылки).

Это совершенно ясно, потому что щелчок по ссылке — это четкое состояние, в котором веб-разработчик точно знает, где находится пользователь в данный момент — абсолютно независимо от того, что пользователь делал до этого (например, несколько раз нажимал кнопку «Назад» в браузере). . Затем стек навигации строится на основе этого нового состояния.

Резюме: Становится ясно, что это будет не лучшее решение. Но он позволяет хранить в стеке дополнительную информацию, такую ​​как параметры страницы и некоторые другие полезные вещи (возможны дальнейшие разработки).

Итак, как вы решили эту проблему?

ваше здоровье,

мана


person mana    schedule 16.09.2008    source источник


Ответы (1)


Решение со стеком звучит интересно, но оно, вероятно, сломается, если пользователь решит перемещаться «параллельно» по разным вкладкам или с помощью закладок.

Боюсь, я не очень понимаю, почему вы должны хранить все это состояние для каждого пользователя: в идеале сеть должна следовать принцип REST и быть полностью апатридом. Поэтому один URL-адрес должен идентифицировать один ресурс без необходимости вести историю переходов каждого пользователя.

Если ваше веб-приложение сильно зависит от AJAX, вы можете попробовать реализовать что-то вроде GMail (правда, не так просто...), где каждое изменение в интерфейсе отражается в изменении URL-адреса страницы. Поэтому каждая страница идентифицируется текущим URL-адресом, и пользователь может одновременно перемещаться по ней или использовать кнопку «Назад», как обычно.

person LorenzCK    schedule 16.09.2008