Как отображать сообщения пользователю после перенаправления POST + HTTP - PullRequest
Новая
       31

Как отображать сообщения пользователю после перенаправления POST + HTTP

21 голосов
/ 29 июня 2009

Я использую шаблон PRG , чтобы избежать многократной отправки формы. Однако он имеет серьезный недостаток - вы не можете просто echo подтвердить сообщение пользователю (очевидно, пользователь не увидит страницу, он будет перенаправлен на другую).

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

  • Используйте пользовательский URL перенаправления, например: http://example.com/?msg=data-saved. Это без гражданства, поэтому я думаю, что это довольно надежно. Но это создает проблемы, когда пользователь копирует ссылку, добавляет ее в закладки и т. Д.
  • Сохраните переменную сеанса / cookie и проверяйте ее при каждой загрузке страницы. Если он установлен, очистите его и отобразите сообщение. Кажется, все в порядке, но я не уверен насчет этого - он сильно зависит от куки, он немного сложнее.

Или, может быть, есть другие способы, о которых я не знаю? Некоторая комбинация сессий и параметров URL? Незнайка.

Какой, по вашему мнению, лучший способ? Какой из них имеет наименьшие недостатки? Какие плюсы и минусы?

Ответы [ 6 ]

9 голосов
/ 29 июня 2009

Есть несколько других вопросов о переполнении стека, которые касаются этого, хотя я не думаю, что кто-либо так ясно описывает проблему. Вот некоторые из них:

Большинство удобных решений основаны на сеансах или имеют более серьезные недостатки (например, встраивание сообщения в строку запроса).

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

6 голосов
/ 11 июля 2009

Если вы не хотите полагаться на сеансы по какой-либо причине, вы можете использовать переменную Get / custom url, а затем, если эта переменная присутствует, проверьте ссылку. Если ссылка верна, отобразите сообщение. Да, это добавляет зависимость от ссылок, отправляемых для отображения подтверждающего сообщения, но в противном случае вы полагаетесь на сеансы (которые хотя и надежны, но не на 100% идеальны для всех решений).

И, честно говоря, некоторые крупные сайты, которые обычно довольно хороши в такого рода вещах, просто вставляют "actiondone = true" в URL. (Я заметил, что Facebook делает это в некоторых местах.)

3 голосов
/ 29 июня 2009

Это зависит от того, на какой платформе вы работаете.

Ruby on Rails вызывает эту вспышку [: note] = "Ваше действие выполнено", ASP.NET MVC вызывает эту TempData ["note"] = "Ваше действие выполнено" ...

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

2 голосов
/ 11 марта 2010

Очень поздно к этому обсуждению ..

Вы можете использовать комбинацию двух предложенных вариантов.

После запроса POST клиент перенаправляется (303) на URL, указывающий, что может быть ответное сообщение для этого запроса: 

Client: GET  http://example.com/foo.cgi
Server: 200  Ok

Client: POST http://example.com/bar.cgi
Server: 303  http://example.com/foo.cgi?msg=true

Если аргумент msg равен true, сообщение будет найдено в сеансе и (если найдено) включено в ответ клиенту.
Если аргумент msg равен ! true (или отсутствует), шаг поиска пропускается.

С помощью этого решения вы предотвращаете показ фактического сообщения в URL-адресе, URL-адрес только указывает, что это сообщение может быть. Кроме того, сообщение отображается только при необходимости (= при обнаружении в сеансе).

Другое преимущество состоит в том, что это решение также позволяет включать надлежащие средства контроля наличности в ответы HTTP.

1 голос
/ 29 июня 2009

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

Также обработка сессий является одной из тех вещей, о которых обычно заботится фреймворк веб-разработки.

1 голос
/ 29 июня 2009

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

...