On Wed, Apr 13, 2011 at 12:34 PM, Stuart Dallas <stuart@xxxxxxxx> wrote: > On Wednesday, 13 April 2011 at 19:15, Nathan Nobbe wrote: > On Wed, Apr 13, 2011 at 12:04 PM, Stuart Dallas <stuart@xxxxxxxx> wrote: > > > On Wednesday, 13 April 2011 at 18:55, Nathan Nobbe wrote: > > > On Wed, Apr 13, 2011 at 11:49 AM, Jim Giner < > jim.giner@xxxxxxxxxxxxxxxxxx>wrote: > > > > > > > > > Can one create a set of $_POST vars within a script or is that not > do-able? > > > > > My display portion of my script utilizes the POST array to supply > values to > > > > > my input screen - this works well for the first display of an empty > screen, > > > > > and any following re-displays if there's an error in the user's > input. But > > > > > I want to use this same script/screen to display the results of a > query > > > > > when > > > > > the user wants to update an existing record. > > > > > > > > > > > > While a user script can populate $_POST this is generally prohibited > as it's > > > > typically populated by the environment. > > > > > > > > It would probly be cleaner to have the display portion of your script > read > > > > from an arbitrary array. > > > > > > > > Said arbitrary array could be populated by $_POST in one case and the > > > > results of a query in another case. > > > > > > While I don't necessarily disagree with you as far as abstracting the > source of data goes, but it's never "prohibited", it just considered bad > practice. > > > > considered a bad practice means prohibited for most groups ive worked > with. > > This isn't any of the groups you've worked with, this is the wide world and > it's full of possibilities. > lol youre right, and none of the groups ive worked with have been part of this global community, so these must be strictly new possibilities we're discussing on this thread... > > Personally I've never understood this "thou shalt protect the > superglobals" attitude. They're arrays, nothing more, use them in whatever > way you want to. They're not sacred, endangered or likely to be overcome > with the urge to kill you if you modify them. If your code changes its > behaviour depending upon whether the data you're dealing with has come from > within or without your code I think you have bigger style issues to address. > the reason it's a bad practice is it undermines an assumption that $_POST > is only being populated by the environment, which in the case of $_POST is > coming from a form field, ajax / curl request etc. as soon as that > assumption is thrown out the window debugging becomes more involved trying > to track down the mysterious appearance of a $_POST var. if you really need > to store arbitrary data in a supergloabal $GLOABALS is there for that; def > don't stuff these into $_POST :) > > My idea of "best practice" says that data coming in from outside your code > should only ever be dealt with in the first script the request hits, so you > should never be hunting for where an errant value in $_POST came from. Given > this (and noting the fact that this was your suggestion to the OP) you're > creating the problem you're trying to avoid by using an "arbitrary array" in > the place of $_POST. > well when you build programs that are more than one script in length you'll find that data submitted by the user is often referenced further in the flow than the entry script.. read: front controller. and im not creating a problem, im avoiding a problem by not overloading the intended use of the $_POST array. > My response to the OP was simply answering the question. right, don't bother to offer any insight to a beginner, undermining the benefit of a list like php-general. > He has a section of code that uses $_POST and he wants to know if he can > populate that within his code rather than needing it to come from a request. > Why he didn't just try it is beyond me, but all this talk of best and bad > practice is all beside the point. > no, it's the entire point. if you ask a question on this list you should expect to get more than a black and white answer. that's how people get better quicker and that's the point of interacting with humans on the other end of the wire. > > keep things cleanly separated and you'll thank yourself later imo. also > when someone is asking a question of this nature, obviously this is the most > critical time to tell them about bad practices rather than just the obvious, > "yes, of course you can do that...". otherwise people asking questions won't > get much more mileage from this list than a google search. > > It's bad practice for reasons that arise equally well from abstracting the > source of data, as you suggested. Why, then, is it bad practice? no, it's actually a better practice. users are expected to populate arrays they create. the $GLOBALS array is expected to be populated by user scripts. The $_POST array is expected to be populated by PHP. by the time you've decided to stuff variables into $_GET or $_POST yourself you've decided to start mixing variables from your code with variables from the client. simply put these arrays are not intended to be populated by user scripts. -nathan
