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

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

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

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

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

Требуется:

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

Некоторые из предложенных мной вариантов:

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

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

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

Ответы [ 9 ]

6 голосов
/ 20 ноября 2008

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

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

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

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

3 голосов
/ 20 ноября 2008

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

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

3 голосов
/ 20 ноября 2008

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

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

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

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

1 голос
/ 20 ноября 2008

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

1 голос
/ 20 ноября 2008

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

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

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

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

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

0 голосов
/ 29 ноября 2008

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

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

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

0 голосов
/ 20 ноября 2008

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

}

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

0 голосов
/ 20 ноября 2008

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

0 голосов
/ 20 ноября 2008

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...