Блог

Эти вопросы касаются списков данных в бэк-офисе с такими переменными, как порядок, # страницы, фильтр и т.д..

Раньше я передавал эти переменные между страницами с помощью GET, но у меня было много проблем, и я перешел на хранение этих переменных в сеансе. Я не возражаю против проблемы с закладками, поскольку это инструмент бэк-офиса. До сегодняшнего дня все было нормально: я просматривал список, я изменил один фильтр, а затем я хотел вернуться к предыдущим результатам. Моим естественным жестом было нажатие кнопки браузера «Назад». Конечно, я не перешел к предыдущим результатам, потому что я перезаписал сессию.

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

Проблемы, которые я обнаружил, когда передавал переменные по URL, особенно в списках двух или трех уровней:

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

Я полагаю, что лучшее решение — это не «Эй, если вы будете уделять больше внимания, вы не будете совершать эти ошибки». Есть ли какая-либо система, которую я еще не обнаружил? Как великие это делают?

Возможно, реализация методов для автоматического отображения ссылок?

Спасибо.

Местом для этих типов переменных является строка запроса. Это необходимо не только для создания закладок, но и для перехода к заданному контенту в целом, как вы обнаружили с помощью кнопки «Назад». Однако, если вы действительно хотите сократить строку запроса, рассмотрите возможность использования токена или идентификатора вместо этого.

То есть в сеансе рассмотрите возможность использования системы, подобной этой:

 // this represents the query data for one page request
$_SESSION['queryid']['38hghfd85423lk'] = array(
    'all' => array('the => 'query', 'data'),
    'is' => array('stored', 'like', 'this)
);

// this represents the query data for another page request
$_SESSION['queryid']['432423jkgrfsd9'] = array(
    // .... other data ....
);
  

Теперь ваша строка запроса будет выглядеть следующим образом:

 http://www.example.com/index.php?queryid=38hghfd85423lk
  

Или вот так:

 http://www.example.com/index.php?queryid=432423jkgrfsd9
  

Конечно, вы используете queryid, указанный в GET data, чтобы определить, из каких данных запроса использовать $_SESSION . Теперь кнопка возврата браузера будет работать.

Проблема может заключаться в том, что после длительных сеансов кэш запросов в $_SESSION станет довольно большим. Чтобы смягчить это, вы можете ограничить длину кэша, скажем, последними 100 страницами. Если пользователь попытается перейти более чем на 100 страниц назад, вы заметите, что его queryid больше не существует, и сможете уведомить его о том, что срок действия страницы истек.

Если вы хотите поддерживать создание закладок, вы можете сохранить идентификаторы запросов и данные в базе данных. Конечно, вам все еще может потребоваться рассмотреть методы сокращения — скажем, идентификаторы запросов, которые не использовались в течение месяца, очищаются. Однако это может расстраивать пользователя.