On Thursday, 14 April 2011 at 23:08, Nathan Nobbe wrote:
On Thu, Apr 14, 2011 at 2:53 AM, Stuart Dallas <stuart@xxxxxxxx> wrote:
> > 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?
>
> 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 disagree.
-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
