On Mon, Jan 12, 2009 at 3:03 PM, Ashley Sheridan <ash@xxxxxxxxxxxxxxxxxxxx> wrote: > I tend to use $_REQUEST to capture a lot of my data, as I end up mixing > get and post a lot throughout my code. $_REQUEST is an amalgamate of > $_COOKIE, $_GET and $_POST (in that order I believe, with $_GET > overwritting $_COOKIE, and $_POST overwriting $_GET). This is especially > useful when altering how a form sends data. Only today we had to update > a form to use GET instead of POST, as IE managed to break the back > button because of the POST values not auto-submitting. It would have > meant a lot of code changes had $_REQUEST not been used. It's okay if you want to do such things, but I really wouldn't recommend it. It leads to buggy apps (from almost every example I've ever seen). Most code I've seen using $_REQUEST doesn't validate it either which would be the loophole to it. Any app allowing user input should function no matter where it comes from or what it is, but still why not be very clear about it. GET is for the state of the page & POST is for data. So you really shouldn't mix the two concepts. If I need to display a form based on an id I might have a url that looks like /form.php?id=x which indicates I'm working with id x and it will make the post action also have id=x in the query string since it is the resource I'm working on, not the data. That save page will still technically have a GET & POST mixed, but they're two totally different things. You can fix IE back button problems with the PRG pattern [1]. It's kind of lame but I got over that after not having to see page expired anymore. [1] http://en.wikipedia.org/wiki/Post/Redirect/Get -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
