Im использует шаблон PRG, чтобы избежать множественного представления формы. Тем не менее, это серьезный недостаток - вы не можете просто echo подтвердить сообщение пользователю (очевидно, пользователь не увидит страницу, он будет перенаправлен на другой).
Каковы решения этой проблемы? Я знаю двух из них, но ни один из них не кажется идеальным.
http://example.com/?msg=data-saved. Его безграждан, поэтому я считаю его вполне надежным. Но это создает проблемы, когда пользователь копирует ссылку, заносит закладки и т.д.Или, может быть, есть другие способы, о которых я не знаю? Некоторая комбинация сеансов и параметров URL? Незнайка.
Какой лучший способ, на ваш взгляд? У кого есть наименьшие недостатки? Каковы плюсы и минусы?
Практически каждый веб-сайт, который позволяет пользователям регистрироваться, делает это, полагаясь на файл cookie. Это не идеальное решение, но это лучшее, что мы получили.
Также обработка сеанса - это одна из тех вещей, которые обычно заботятся о веб-разработке.
Есть несколько других проблем с переполнением стека, которые касаются этого, хотя я не думаю, что это достаточно четко изложить проблему. Вот несколько:
Большинство удобных решений основаны на сеансах или имеют более серьезные недостатки (например, встраивание сообщения в строку запроса).
Если вы не можете гарантировать, что у вас будут сеансы, другой (довольно дорогостоящий) метод - перенаправить на разные представления в зависимости от результата подачи формы. Например, вы можете перенаправить на EditWidgetView, EditWidgetSaveSuccessfulView или EditWidgetSaveErrorView (или, возможно, вы просто не перенаправляете на ошибки). На некоторых языках и в каркасах это нецелесообразно, так как вы отказываетесь от отображения сообщений о подтверждении/ошибке вообще, но в других это может быть полезно.
Если вы не хотите полагаться на сеансы по какой-либо причине, вы можете использовать переменную Get/custom url, а затем, если эта переменная присутствует, проверьте ссылку. Если ссылка правильная, тогда отобразите сообщение. Да, это добавляет зависимости от отправленных ссылок, чтобы отобразить подтверждающее сообщение, но в противном случае вы полагаетесь на сеансы (которые, будучи надежными, не на 100% идеальны для всех решений.)
И, честно говоря, некоторые крупные сайты, которые обычно хорошо разбираются в подобных вещах, просто вставляют "actiondone = true" в url. (Я заметил, что Facebook делает это в некоторых местах.)
Это зависит от того, на какой платформе вы работаете.
Ruby on Rails вызывает эту вспышку [: notice] = "Ваше действие выполнено", ASP.NET MVC вызывает этот TempData [ "notice" ] = "Ваше действие выполнено"...
В основном они просто хранят данные в HttpSession только для одной поездки в оба конца. Таким образом вы можете получать данные по другому веб-запросу.
Очень поздно приступить к обсуждению.
Вы можете использовать комбинацию двух предложенных опций.
После запроса 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.
Я использую метод переменной сеанса. Мне не очень нравится встраивать сообщения об ошибках для отображения в URL-адресе, особенно с учетом проблем с сохранением URL-адреса и совместного использования, и мне нравится, что если пользователь перезагрузит целевую страницу, это будет чистый экземпляр.