On Mon, Jan 12, 2009 at 3:34 PM, Robert Cummings <robert@xxxxxxxxxxxxx> wrote: > On Mon, 2009-01-12 at 15:29 -0500, Eric Butera wrote: >> On Mon, Jan 12, 2009 at 3:21 PM, Robert Cummings <robert@xxxxxxxxxxxxx> wrote: >> > 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. >> > >> > Most systems using a front-end loader to get to a page containing a form >> > wouldn't work if you DIDN'T mix the two concepts. >> > >> > Cheers, >> > Rob. >> > -- >> > http://www.interjinn.com >> > Application and Templating Framework for PHP >> > >> > >> >> I use MVC w/ front controllers all the time. I dunno what you're >> talking about though so hopefully you can elaborate more. >> >> demo_form would accept GET id=1 >> demo_save would accept GET id=1 and POST name, description, etc > > Front end controller usually receives a GET variable indicating what > page or content is being requested... add a form with POSTed data and > you need to mix GET and POST. unless you go through the hoops of putting > the front end loader information into the form. There's absolutely > nothing wrong with mixing GET and POST as long as you know what you're > doing. > > Cheers, > Rob. > -- > http://www.interjinn.com > Application and Templating Framework for PHP > > Yep. I guess I was just trying to define what knowing what I'm doing meant. My url might have id=1 in it, but that is the only thing. On a post page I still need that id=1 in the url because it has to know what record to update. Some could argue to throw that in the form itself, I used to even, but over time it has just made more sense for it to be in the url since it defines what page/record you're working with. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
