On Thursday, 14 April 2011 at 07:11, Nathan Nobbe wrote:
On Wed, Apr 13, 2011 at 3:30 PM, Stuart Dallas <stuart@xxxxxxxx> wrote:
> > On Wednesday, 13 April 2011 at 19:47, Nathan Nobbe wrote:
> > 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.
> Who said you should make assumptions. One thing you know is that $_POST was populated by the contents of HTTP POST, or most of it anyways, lol.
Again, I don't see how that "knowledge" is useful?
> Here's an example, suppose you have an object, any object in php should let you dynamically create a public member variable on it on the fly unless there's an explicit override in __get().
>
> $oXml = new SimpleXmlElement('<vendor-data><content>real-data</content></vendor-data>');
>
> now someone decides to use it to store something clever, because they can, and it's so much easier than creating an appropriate location
>
> $oXml->myCleverValue = 'something unrelated';
>
> whoops the client web service stopped processing our request successfully because the clever new node inadvertently broke the validation against the xsd.
>
> or I'm running through some code and see it in a for loop
>
> foreach($oXml as $node => $value)
>
> but I don't see any clever value in the docs from the vendor..
>
> Separation of concerns for data. The same reason you have a typical directory structure on an operating system and the same reason you don't have 10 projects all in the same vcs repository. but nothing is written in stone..
Whoa, whoa, whoa! At what point did I say I think it's ok to put arbitrary data into $_POST? As I said in a previous email, I was responding to the OP's question which was essentially "is it possible to fake a form post" and the answer is yes. I have at no point advocated using $_POST for data that you simply want to be globally available.
> > 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?
>
> the first place you look for data in the $_POST array is the client layer. it doesn't matter if they were populated by php or apache, the important part is what the container is supposed to store, what it represents. A common issue that was recently brought up on the list is the typical abuse the $_SESSION array gets in PHP applications. $_POST is no different, though in my experience it's not abused as frequently, most people seem to just get it, but then, nothing's written in stone.
>
> > 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?
>
>
> It's not where the data came from, it's what the data represents. I worked on an application several years ago where values were gratuitously placed in all of the superglobal arrays. The application had some crude database layer that was stuffing the mysql_insert_id into $_POST. So you might see some code like
>
> // do some real work, and by the way insert a record into the db
>
> // then later on
> $ourNewWhateverID = $_POST['NEW_ID'];
>
> well the first assumption is that that value had to come from the browser (only client in this application) so you start looking through html forms and javascript code (running grep through the template directories etc)... maybe it's set dynamically by some javascript code and passed over in an ajax request... or it was passed along by the previous page.., or no, maybe someone who used to code here didn't realize they could put it in the $GLOBALS array where other programmers expect to find user space values ... or better yet, they might not use the global context for this sort of thing at all... but no, you had to go ahead and
>
> $_POST['NEW_ID'] = mysql_insert_id();
>
> I'm not sure where your meter on best practices falls, but in my book even if the key was 'LAST_INSERT_ID' i'd chalk it up to brain dead. Let's take a dynamically generated value from the database and put it in a structure understood to be populated by data from the request; brilliant!
My point is and has always been that there is nothing inherently wrong with setting or modifying values in $_POST. I agree that it is bad practice to use $_POST for arbitrary stuff, but I see nothing wrong in setting or modifying values to enable another part of your code to process that data as if it had been POSTed, which is what the OP was wanting to do.
> The only real value I see to setting values in the $_REQUEST et al arrays is unit testing.
IOW, faking a request which, again, was what the OP wanted to do!
A couple of final points of personal opinion...
* Any code that simply iterates over an array assuming it only contains the things it wants is poorly written and the developer(s) should be shot.
* Any shared code that uses the superglobals is equally poorly written and the developer(s) should be shot.
* Any shared code that makes assumptions about the contents of superglobals is equally poorly written and the developer(s) should be shot.
In my experience assumptions are the cause of more bugs than anything else. If your code does expect the unexpected, you should be shot.
For some reason I want lots of people to be shot today, and it's not even 10am yet!
-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
