I can't agree with that--you proved me wrong once, so lets see if you can't do it again!Everah wrote:You should always distinguish between your superglobals. It makes for clean, maintainable, readable code later on. If you know it is coming from POST use POST, if it is coming from GET use that.marcth wrote:I guess I'm going to have to start using a hidden variable called formAction--I really don't want to distinguish between get and post variables.
I would not use REQUEST (yes, that is a bit of a holy war around here... search and you will find all sorts of opinions about it) because PHP sets a precedent order on REQUEST, one that is tested in the code I posted above.
Thesis: Accessing HTTP request variables via the the REQUEST scope is easier and makes for more readable than accessing user-supplied data via the GET and POST scopes.
Assumptions: Submitting a GET and POST variables of the same name in one request is confusing and makes for unreadable code. For example:
Code: Select all
<form action="index.php?id=1">
<input type="hidden" name="id" value="2" />
</form>
- Request variables submitted via POST is just as insecure as data submitted via GET (or via a cookie for that matter)--one cannot be trusted more than the other.
- Accessing user data from one single source (REQUEST) is simpler than accessing it from multiple sources (GET, POST).
- Your views can be refactored to submit GET variables as POST variables and vice versa (should the need arise) without having to worry about the server-side scripts.
- Users can bypass your interface (ie form) and submit data directly via the URL (Think: sending a partially completed from via email as a practical example).
- [Edit] Forms submitted via Ajax may not be submitted via GET