On Wednesday, 13 April 2011 at 19:47, Nathan Nobbe wrote: > On Wed, Apr 13, 2011 at 12:34 PM, Stuart Dallas <stu...@3ft9.com> wrote: > > 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. > > 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...
I clearly didn't put my point across well enough, which was that what is and what isn't best practice is not set in stone. Best practices vary from group to group and from project to project, and that's the way it should be. However, just because you've mostly worked in groups where this is bad practice does not make it bad practice. > > > 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. Good at making assumptions, aren't you?! Anyway, again, you seem to have missed my point. In a front controller architecture, in my opinion, no code beyond that front controller should ever be referencing the get, post or cookie superglobals, and ideally not the server superglobal either. This, to me, is the equivalent of having all variables a system uses as globals which, I hope you'll agree, is something everyone agrees to be bad practice. > > 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. Again, your insight is from your perspective. It's an opinion, and one I don't share, hence why I didn't mention it. > > 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. Again, modifying $_POST is bad in your opinion (and a fair few others I'll grant you), but it is not forbidden, against the rules or likely to destroy the world one website at a time. What you call insight, I call company policy. > > > 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. I never make any assumptions about the source of any data when I'm developing software, whether in PHP or not. Returning to a previous point, usage of global variables as the source of data anywhere other than the initial script a request hits is tantamount to negligence. But that's just my opinion. But here's a question that just occurred to me... what are you doing differently based on the assumption that those arrays are populated by PHP? Seems to me that data in those arrays should be treated more carefully than any other data, so why you feel you need to know where they came from is beyond me. Can you elaborate? -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
