On Wednesday, 13 April 2011 at 19:15, Nathan Nobbe wrote: On Wed, Apr 13, 2011 at 12:04 PM, Stuart Dallas <stu...@3ft9.com> wrote: > > On Wednesday, 13 April 2011 at 18:55, Nathan Nobbe wrote: > > On Wed, Apr 13, 2011 at 11:49 AM, Jim Giner > > <jim.gi...@albanyhandball.com>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. > 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. My response to the OP was simply answering the question. 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. > 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? -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
