Best practice: Self-referential scripts on a web site

Question

On the advice of a more experienced developer, I have always coded my web pages that require user input (form processing, database administration, etc.) as self-referential pages. For PHP pages, I set the action of the form to the 'PHP_SELF' element of the $_SERVER predefined variable, and depending on the arguments that I pass the page logic determines which code block(s) to execute.

I like that all of the code is contained in one file, and not spread around to various result pages. The one issue I've found is that my stats parsing programs can't differentiate between the first view of the page, and subsequent views (e.g. when the form has been submitted). A long time ago, when I used CGI or CF to create the pages, I directed the user to a different result page, which showed very neatly how many times the form was actually used.

What is the best practice for these types of pages in web development? Are there other, more compelling reasons for using (or not using) self-referential pages?

Answer 1

One potential option would be to set up mod_rewrite aliases that point at the same URL. For example:

RewriteEngine on
RewriteRule ^form$ form.php [QSA]
RewriteRule ^form/submit$ form.php [QSA]

This would allow you to track requests while maintaining the code in the same file.

Answer 2

You could use separate pages, and just have the results page include the form page.

Answer 3

I would argue that self-referential pages, as you put it, do not follow an appropriate separation of concerns. You're doing 2 different things with the same page, where a cleaner separation of logic would have you do them in 2 different pages.

This practice is emphasized by MVC (model-view-controller, http://en.wikipedia.org/wiki/Model-view-controller) frameworks, such as Ruby on Rails, Django, and ASP.NET MVC (I don't know any PHP ones off the top of my head, though I am sure there are some).

This is also an essential feature of RESTful (REpresentational State Transfer) practices, where each URL represents a resource and a single action to be performed with that resource. A self referential page, on the other hand, would have "2" actions per URL/page, such as "new" (to get the form to fill out) and "create" (to actually create the object).

Practicing MVC and RESTful (http://en.wikipedia.org/wiki/RESTful) practices for websites often results in cleaner code and a better separation of concerns. The reason this is important is that it makes for easier testing (and by testing I mean unit and functional testing, not "trying the page on my browser" testing).

The cluttering of your statistics is an example of how not separating your concerns can lead to un-intended complexity. Some people might approach this problem by trying to detect the referrer of the request, and see if it was the same page or not. These are all really just code-bandages that address the symptom, instead of fixing the problem. If you keep different "actions" in different pages in your website, you can focus those pages on their 1 job, and make sure they do it well, instead of cluttering the code with all sorts of conditionals and additional complexities that are completely avoided if 1 page only has 1 job.

Answer 4

The strongest argument behind the single file approach for form handling is that it's simply easier to maintain.

Allow me play devil's advocate: if your original two file approach works and is measurable, why change it -- particularly if changing it forces you to come up with workarounds to measure the form submission?

On the other hand, if you're dealing with something more complex than what I'm imagining as a simple contact form submission (for example) then it might behoove you to learn how to log your actions instead of depending on a web stats package.