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

Question

Итак, цепочка событий:

1. Пользователь отправляет форму.
2. Во время обработки представления генерируется сообщение, например "Ваша запись была сохранена".
3. Пользователь перенаправляется на новую страницу, скажем, результаты поиска.
4. Новая страница должна отображать сообщение.

Итак, вопрос в том, как получить сообщение с шага 2 на шаг 3? Это только один простой пример... Есть много других, более сложных примеров.

Я использую PHP.

Потребности:

• поддерживает несколько сообщений и должен быть отформатирован на принимающем компьютере, как требуется
• сообщения могут быть добавлены на той же странице (например, на шаге 4)
• сообщения, добавленные изнутри любой функции или объекта

Некоторые варианты, которые я придумал:

• хранить в переменной сеанса в виде массива и очищать после каждого отображения
• передать как параметр get или query; может раздражать, потому что вы постоянно обрабатываете это и должны помнить, чтобы получить это; так как он может быть длинным, он может легко превысить максимальную длину строки запроса
• хранить в базе данных для каждого сеанса (не всегда для зарегистрированного пользователя); для этого потребуется дополнительная вставка на каждую страницу, где они добавляются, возможно, несколько, и дополнительный выбор на каждой странице

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

Редактировать: я использую 2 функции для метода сеанса: AddStatusMsg() (добавляет элемент в массив) и DisplayStatusMsg() (возвращает сообщение в формате HTML и очищает массив).

Answer 1

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

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

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

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

Answer 2

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

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 может быть "предупреждение", "ошибка", "успех" и т. д. и в зависимости от типа вы можете показать пользователю другое изображение / цвет / что угодно.

Answer 3

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

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

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

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

Answer 4

Вероятно, лучший способ - сохранить его в сеансе. Это самый простой способ, и, как сказал Джон, "не усложняй вещи".

Answer 5

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

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

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

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

Ничего подобного. Не усложняйте вещи.

Answer 6

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

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

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

Answer 7

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

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

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

Answer 8

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

Answer 9

Я думаю, что вы делаете это правильно. Вы должны держаться подальше от базы данных для этого, и поместить его в 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();
}

}

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