On Mon, 2009-01-12 at 15:15 -0500, Eric Butera wrote: > 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 I like that idea actually, I'll try and work it into the next projects, as it would fix the problem rather than work-around it. Ash www.ashleysheridan.co.uk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
