Лучшие практики для Post-Redirect-Get (PRG) с MVC в PHP - PullRequest
Новая
       26

Лучшие практики для Post-Redirect-Get (PRG) с MVC в PHP

9 голосов
/ 09 мая 2011

Есть ли лучшая практика для PRG паттернов с MVC?
В этом руководстве:
http://www.theserverside.com/news/1365146/Redirect-After-Post
предлагаемому решению требуется 4 действия:
Create_Item (POST) => «сбрасывает» форму и перенаправляет на Display_Item
Display_Item (GET) => показывает форму (с временными данными и ошибками, если существует)
Store_Item (POST) => попытаться сохранить данные в БД, еслиошибки, сохраните ошибки и перенаправьте на Display_Item, если успешное перенаправление на Display_Stored
Display_Stored (GET) => показывает созданный элемент или сообщение об успешном выполнении, tec.

Теперь я думаю, что иметь первое действие с POST - это проблема, потому что мы не можем запустить форму со ссылкой.Использование GET в Create_Item кажется лучшим вариантом.
А также мы можем сделать то же самое с 3-мя действиями (используя одно и то же действие для Create_Item и Display_Item, но с дополнительным флагом для сброса формы, например:
http://www.example.com/controller/Create_Item/?reset=1

А также мы можем сделать то же самое всего с двумя действиями, потому что мы можем использовать if inside Create_Item для проверки, является ли запрос GET или POST (поэтому мы комбинируем Display_Item сStore_Item).

А также мы можем сделать то же самое всего с одним действием, потому что у нас может быть дополнительный флаг (в запросе URL или в сеансе) для отображения результатов вместо формы:
GET http://www.example.com/controller/Create_Item/?reset=1 => показывает новую форму и перенаправляет на следующий URL
GET http://www.example.com/controller/Create_Item/ => показывает форму с временными данными и ошибками, если существует
POST http://www.example.com/controller/Create_Item/ => сохранить ошибки в temp или данные в БД (и установить флаг сеанса для успеха) и перенаправить на указанный выше URL или следующий URL
GET http://www.example.com/controller/Create_Item/ => if $ _SESSION ['success'] показатьрезультаты

Лично мне нравится идея иметь 4 действия,но у меня нет никакого реального преимущества перед другими вариантами.Но я не чувствую себя в безопасности, выбирая свой дизайн без реальных критериев.
Кто-нибудь знает PROS и CONS каждого дизайна (если есть)?

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

Спасибо!

1 Ответ

4 голосов
/ 09 мая 2011

Шаблон представляет собой GET пустую форму, измените содержимое формы, затем POST это на сервер, который затем отправляет перенаправление на другую страницу, которая является GET, возможно, на страницу, говорящую Form submitted successfully.. (Get ->) пост-> Redirect-> Get

Первое действие не совсем POST. Это конечный результат заполнения формы и ее отправки. В руководстве больше говорится о том, что делать после этого POST, так как если вы не выполняете перенаправление, пользователь остается на странице с сообщением Form submitted successfully, где он может просто нажать F5 и сделать еще один POST. Однако с этим перенаправлением они попадают на страницу результатов через безопасный GET, который не приведет к двойному сообщению.

Что касается реализации, у каждого из вас должно быть свое собственное действие на стороне сервера. Это соответствует реализации MVC / RESTful.

  • GET / url? Action = new -> Вызовите метод new_form () для отображения новой формы
  • POST / url? Action = create -> Вызовите метод create_form () для сохранения и перенаправления в / url? Action = show & id = 1234
  • GET / url? Action = show & id = 1234 -> Вызвать метод show_form () для отображения результата
  • POST / url? Action = save & id = 1234 -> Вызовите метод save_form () для сохранения и перенаправления

Вместо этого вы можете использовать 3 действия, если хотите, чтобы 2-е действие вызывало save. Большинство соглашений REST / CRUD используют 4, но выбор остается за вами. Преимущества те же, что и при прохождении маршрута REST / MVC.

См. Также эти ресурсы:

  • RESTful веб-сервисы
  • Это охватывает типичные соглашения для контроллеров RESTful. Он охватывает рельсы, но все еще применяется к PHP, если вы хотите пойти по маршруту REST.
...