Как лучше передать сообщение пользователю между страницами

Я бы порекомендовал AGAINST хранить эти сообщения либо в базе данных, либо в сеансе по одной простой причине: вкладкам. (Ну, действительно, безгосударственный характер HTTP.)

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

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

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

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

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

Вы также можете использовать для этого отдельный div, созданный главной страницей, и пусть позиция будет обрабатываться текущей страницей. Если я правильно понимаю, вам нужно какое-то время между показом сообщения и перенаправлением пользователя на другую страницу. Это может быть достигнуто с помощью любой библиотеки AJAX, чтобы показать, что div я сказал ранее, а затем перенаправляюсь на новую страницу.

Я предлагаю взглянуть на jQuery .

Вот как мне это нравится:

function set_message($message_type, $message) { $_SESSION['messages'][$message_type][] = $message } function get_messages() { $messages_array = $_SESSION['messages']; unset($_SESSION['messages']); return $messages_array; } 

где $message_type может быть «предупреждением», «ошибкой», «успехом» и т. д., и в зависимости от типа вы можете показать пользователю другое изображение / цвет / что угодно.

Эта проблема является классическим примером того, как данные сохраняются в «протоколе без учета состояния», таком как http.

Ваши варианты:

1. Передайте его в параметрах GET (не для пользователя)
2. Храните его в БД
3. Храните его в сеансе

Варианты 2) и 3) требуют, чтобы у пользователя был файл cookie (в противном случае нет способа сопоставить пользователя с сообщением). Между ними я бы пошел с встроенными сессиями PHP. Просто установите переменную сеанса на шаге 2, и на странице поиска всегда проверяйте переменную на шаге 4

Ничего. Не переусердствуйте.

Вероятно, лучший способ – сохранить его в сеансе. Это самый простой способ, и как сказал Джон: «Не надо усложнять вещи».

Храните его в базе данных, а также в сеансе. Таким образом, пользователь может добраться до своей истории, если он в ней нуждается, и у вас есть легкий доступ к данным сеанса.

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

Отображение сообщений должно быть частью вашего основного шаблона (другими словами, сделано один раз).

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

Я думаю, вы делаете это правильно. Вы должны держаться подальше от базы данных для этого и помещать его в URL-адрес уродливо. Вы можете написать хороший маленький класс для этого, который может сделать его проще.

Вот небольшой класс занятий:

 <?php class session 

{

 public function __construct() { session_start(); } public function set($name, $value) { $_SESSION[$name] = $value; } public function get($name) { return (isset($_SESSION[$name])) ? $_SESSION[$name] : false ; } public function delete($name) { unset($_SESSION[$name]); } public function destroy() { $_SESSION = array(); #session_destory(); #session_regenerate_id(); } с public function __construct() { session_start(); } public function set($name, $value) { $_SESSION[$name] = $value; } public function get($name) { return (isset($_SESSION[$name])) ? $_SESSION[$name] : false ; } public function delete($name) { unset($_SESSION[$name]); } public function destroy() { $_SESSION = array(); #session_destory(); #session_regenerate_id(); } 

}

Небольшой класс сообщений можно легко создать на этом.

Я нахожусь на этом перекрестке сам, и я подробно рассмотрел все варианты.

1. Как насчет сохранения двух файлов cookie браузера, одной называемой страницей, а другая называется сообщением.
2. При перенаправлении вы перезаписываете файл cookie.
3. Когда страница загружается, вы проверяете, существует ли указанный файл cookie (в заголовках http, отправленных клиентом).
4. Убедитесь, что это для этой страницы, если это так, сохраните сообщение в переменной и отключите файлы cookie.
5. Если это не для этой страницы, проигнорируйте ее, она будет выводиться на другую загружаемую вкладку или если она для страницы, которая по какой-то причине никогда не отключает файл cookie, он в конечном итоге истекает.

Это позволяет избежать использования файлов cookie базы данных и сеансов.