PRG Redefined - Post/Validate/Redirect/Get
Redefining the PRG Pattern with Server-side Validation Included

Published on Aug. 7, 2014 by nick

Tags: form, post, redirect, get

I have been reading up on PRG lately. The Post/Redirect/Get pattern is ubiquitous in most modern day web sites that use the POST method to transfer data from web forms to servers. Logging in, inserting into databases, or whatever, etc. And, as a general rule, you should only validate with JavaScript as a secondary layer, because if the user turns JS off, then no validation will occur. Thus, you should always have a server-side validation routine running... always, always, always.

Now, when I develop with Django, there are many easy and secure ways to do this that come bundled right along with the framework. However, when developing other MVC sites, like with PHP and MySQL, for example, often you will have to write the forms, views and validation from scratch. Sure, you can also use PHP frameworks, but often they are bloated and not necessary.

It just so happens that I maintain a web site for a software company that is written in PHP, and was built from scratch with no framework. I had to add some new forms recently, and so I decided to review my validation and make sure it was working as expected. I found some issues with the code, so I set off to redesign and rebuild much of the form code to adhere to up-to-date PRG standards.

The first thing I noticed is that much of the posting on Stack Overflow, for example, doesn't really discuss much about validation. They basically reiterate that PRG is posting data, doing some database stuff, and then redirecting on success. This is fine, but in my opinion, where to put the validation code and how to do this is very important.

What I want to do, therefore, is define my own, new pattern to reinforce the importance of the validation and database steps: PVIRG... Post, Validate, Insert, Redirect, Get.

Now let's pause here and let me clarify something. I fully understand that several posts do mention validation, and I'm not saying that developers who use PRG are forgetting the validation step; rather, the acronym PRG for the beginner is somewhat misleading. If the validation step, for instance, is discussed more when describing the basic principle, I think fewer developers, especially beginners, would get this very important pattern confused.

I don't want to go into a bunch of code here, because that is outside th scope of this article. What I do want to do is highlight how this might look in pseudocode:

• User visits web form
• Enters data into form
• Clicks submit
• POST data submits to page with validation code
• Validation code validates
• returns errors, if any
• If successful
• insert/update data in database
• redirect to next page
• If not successful
• redisplay orginal form with data prefilled
• Continue the loop until finished

Many posts also talk about where to put this code. This is a valid question, and if you are using some kind of MVC framework, there are probably standards to follow. In the case I'm describing, I used a simple two file configuration. The page with the form and the page for redirection (the form submits POST data to itself where the validation code lives). This may not be the best way to go, and I can imagine using a more modular approach, but for my purposes, it was great. Then, in this validation code, I tested for errors and if found, made them available to the page for redisplay. If there were no errors, the page would validate in success and an action would be carried out. In my case, a simple contact page, it sent email and redirected to a success page. If database operations were required, you could easily carry these out after validation. In general, the process I have described is not much different, if at all, than the standard process that thousands of developers all over the globe use every day. What's new, however, is that I focus on the PRG pattern in a new light, by refering to it as PVIRG, wherein the server-side validation is emphasized.

Let me know what you think. Hopefully some searches will end up here and allow some newbies to get some hints when writing their own applications.