Лучшая практика: как обрабатывать параллелизм браузера и навигации по веб-сайту
Это известная проблема каждому веб-разработчику. Насколько я пытался найти хорошее решение этой проблемы - его не было (или, по крайней мере, я не мог его найти).
Предположим следующее:
Пользователь ведет себя не так, как от него ожидалось. Фактический проект, над которым я работаю, использует навигацию внутри веб-портала. Но если пользователь нажимает кнопку «Назад» в браузере, все становится опасным [?], И результат не всегда был предсказуемым.
Мы использовали структуру struts и сохранили обратный URL-адрес в формах - в некоторых местах, где нам нужен был обратный URL-адрес - он был отображен из обратного URL-адреса этой формы. Поскольку для этой информации было только одно поле, и поэтому было невозможно вернуться на несколько шагов назад.
Когда вы изменяете "поток распорок" - что может привести к использованию другая форма - эта информация будет потеряна.
Если пользователь осмелится поместить закладка где-нибудь в вашем веб-приложении - эта информация, возможно, никогда не была установлена, и снова результат снова будет либо непредсказуемым, либо недостаточно гибким!
Мое "решение":
Я сохранял каждую релевантную для навигации страницу, которую посетил пользователь, в хранилище стеклоподобный в сессия. Это означает, что путь навигации собирается и сохраняется для последующих переходов.
На любой странице в веб-приложении, где используется обратная навигация, я использовал самодельный тег, который отображает содержимое стека в URL-адресе.
И это все. При щелчке по этому обратному URL-адресу стек был заполнен содержимым из обратного URL-адреса, по которому щелкнул пользователь (который содержит всю информацию из стека после визуализации обратной ссылки).
Это совершенно ясно, потому что щелчок по ссылке - это четкое состояние, в котором веб-разработчик точно знает, где находится пользователь в этот самый момент - абсолютно независимо от того, что пользователь делал раньше (например, несколько раз нажав кнопку «Назад» в браузере. раз). Затем на основе этого нового состояния строится стек навигации.
Продолжить: Становится ясно, что это не лучшее решение. Но он позволяет хранить в стеке дополнительную информацию, такую как параметры страницы и некоторые другие полезные вещи (возможны дальнейшие разработки).
Итак, каковы были ваши решения этой проблемы?
ваше здоровье,
мана
Ответы 1
Решение на основе стека звучит интересно, но оно, вероятно, сломается, если пользователь выберет «параллельную» навигацию по разным вкладкам или с помощью закладок.
Боюсь, я действительно не понимаю, почему вы должны сохранять все это состояние для каждого пользователя: в идеале Интернет должен следовать Принцип REST и быть полностью без состояния. Следовательно, один URL-адрес должен идентифицировать один ресурс, без необходимости хранить историю переходов для каждого пользователя.
Если ваше веб-приложение сильно зависит от AJAX, вы можете попробовать реализовать что-то вроде GMail (по общему признанию, не так просто ...), где каждое изменение в интерфейсе отражается в изменении URL-адреса страницы. Таким образом, каждая страница идентифицируется текущим URL-адресом, и пользователь может одновременно перемещаться по ней или использовать кнопку «Назад», как обычно.