Навигация родительского ребенка на нескольких вкладках

Question

, пожалуйста, несите меня для объяснения, это необходимо.

Системный фон: Я создаю дочернюю навигационную систему parent-> для бэкэнд CMS. Я строю URL-адреса, например: [domain.ext]/[moduleName]/[objectName]/[actionName]/[ID #1]/[ID #2].

URL-адрес объяснил (например example.com/PageManagement/Page/Modify/7/13):

• MODULENAME: имя модуля принадлежит объект (например, "PageManagement")
• Objectname: имя объекта (например, «Страница»)
• actionName: название действия (например, "Изменение")
• ID # 1: либо идентификатор записи действие выполняется на, или идентификатор родительского объекта
• ID # 2: идентификатор записи действие выполняется на, но только если ID # 1 заполняется с родительским ID

Навигация происходит путем анализа URL-адресов для его компонентов, сокращения имен для системных идентификаторов и т. Д., А затем получения полей и данных, которые должны отображаться на странице.
Чтобы убедиться, что URL-адрес остается читаемым и логически понятным, я не добавляю несколько URL-адресов родительских идентификаторов в URL-адрес, но сохраняю последние несколько родительских идентификаторов в массиве PHP $_SESSION, поэтому я могу определить при навигации ли другой родительский идентификатор должен быть добавлен.

Пример: изображения есть объекты Page->Extension->Field, которые все в модуле PageManagement и родительские слева направо. Теперь предположим, что у нас есть страница с идентификатором 2, расширение с идентификатором 8 и поле с идентификатором 17. URL-адрес для редактирования поля будет example.com/PageManagement/Field/Modify/8/17, потому что мы редактируем поле 17, которое имеет расширение 8 как родительское. URL для редактирования расширения будет example.com/PageManagement/Extension/Modify/2/8, потому что мы редактируем расширение 8, которое имеет родительский. Редактирование страницы просто будет example.com/PageManagement/Page/Modify/2, потому что у него нет родителя.

Задача: Теперь все это отлично работает. Тем не менее,, если открыты несколько вкладок, они имеют одинаковые $_SESSION, поэтому переход на одну вкладку может отбросить родительскую историю для другой вкладки. Он по-прежнему идет прямо в почти все случаи, но факт I может привести к тому, что это плохо (поскольку кто-то может добавлять/удалять/редактировать данные, не зная, что они действительно находятся в неправильном списке родителей).

Что мне нужно: Мне нужно, с каждым запросом, определить, с какой вкладки он пришел, скорее всего, создав некоторую форму UID на каждую вкладку и отправив ее с каждым запросом. Затем моя система может сохранять историю навигации для каждой вкладки, а не за сеанс.

Рассматриваемые растворы

• генерирования UID на странице сессии, и хранение этого в Window.sessionStorage (который получает сброса для каждого нового окна/вкладки). Это позволит мне генерировать один, если ни один не установлен (так что новая вкладка), и, следовательно, имеет другой хранимый (и запоминаемый) сеанс на странице.
  • Проблема: Я не знаю, как я могу получить, что идентификатор отправляется на сервер с каждым запросом. Файлы сеансов cookie, похоже, разделяются между всеми вкладками (имеет смысл, поскольку они используют сеанс).
• Создание сеанса UID на страницу и добавление его к URL-адресу в виде строки запроса.
  • Проблема: я мог бы также не иметь хорошие URL-адреса, и если кто-то (случайно) редактирует/удаляет его, он все еще не работает. Кроме того, копирование/вставка URL-адреса будет проблемой.
• Создание сеанса UID на страницу и добавление этого URL-адреса до moduleName.
  • Проблема: Это до сих пор видны/редактируемой/съемный, и если они делают это по-прежнему не работает. Кроме того, копирование/вставка URL-адреса будет проблемой.

Если кто-то может решить проблемы, указанные для решения выше, или придумать совершенно новое решение, которое было бы удивительно. Очевидно, что я предпочел бы сделать как можно меньше изменений, как работает система URL, но если это единственное решение, так и быть ...

Answer 1

В вашем дизайне запроса есть основной недостаток, который вызывает у вас все беда.
Система должна стремиться включать всю соответствующую информацию в рамках одного запроса, когда это возможно. В вашем случае это означает отключение механизма, который «запоминает» предыдущие запросы (состояние ..) в $_SESSION и вместо этого передает всю информацию в запросе. Он может быть в URL-адресе («адрес» и/или строка запроса), заголовки, когда это необходимо (обычно использование куки-файлов, возможно, неуместно в этом случае) или тело (так же, как POSTed-формы передают полезную нагрузку).

Есть много причин, чтобы выбрать этот путь, чтобы назвать несколько:

1. Улучшение протоколирования.
2. Легкая отладка.
3. Включите простую ссылку на основе URL (при использовании только URL-адреса для запросов).
4. Уменьшить риск неправильного кэширования (локального или удаленного).
5. Поддержка нескольких одновременных «» запросов -> Поможет преодолеть текущие проблемы :-)

Как всегда, ни одно правило не обходится без исключений. В этом случае наиболее распространенной частью информации, которая НЕ подходит для включения в каждый запрос, является информация аутентификации (имя пользователя, пароль и т. Д.)

Подводя итог, вы должны решительно рассмотреть возможность восстановления ваших запросов таким образом, чтобы все требуемая информация доступна.