On Thursday, 14 April 2011 at 23:08, Nathan Nobbe wrote:
On Thu, Apr 14, 2011 at 2:53 AM, Stuart Dallas <stu...@3ft9.com> wrote:
> > On Thursday, 14 April 2011 at 07:11, Nathan Nobbe wrote:
> >  On Wed, Apr 13, 2011 at 3:30 PM, Stuart Dallas <stu...@3ft9.com> 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?
> you know what doesn't belong there.

It's coming from the client, over which you have no control whatsoever. It 
doesn't matter what you think you know about what it should contain, you 
actually don't know anything about what it does contain and you should write 
your code accordingly. You can't afford to assume anything about data coming 
into your application from sources you don't control.

> > > 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?
> when you suggested to OP to put the result of a query into $_POST. 

Terminology confusion. To me, the "result of a query" is the data, not the 
resource. Personally I think it was pretty clear that's what I meant based on 
what the OP was planning to do, but I can see how that might not have been 
crystal clear.

> >  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
> the question was more like, how do i abstract the input for a template such 
> that it can be supplied data via $_POST in one case and the result of a 
> select in another.

That's not what he asked, but it is one possible answer to his question.

> > I have at no point advocated using $_POST for data that you simply want to 
> > be globally available.
> you've recommended populating $_POST with data that has nothing to do with 
> HTTP POST, it is by nature globally available.

I have suggested that there is nothing wrong with modifying data in the $_POST 
global variable to essentially fake that it had come from a form post. I never 
suggested that it should be used as a generic global store.

I think we've started going around in circles and this is no longer benefiting 
anyone. I think we're essentially saying the same thing, but where you're 
relying on rules around how $_POST should be used I'm advocating vigilant 
defensive programming techniques, and it seems we're going to have to agree to 


Stuart Dallas
3ft9 Ltd

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to