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:
> > On Wed, Apr 13, 2011 at 12:34 PM, Stuart Dallas <stuart@xxxxxxxx> wrote:
> > > On Wednesday, 13 April 2011 at 19:15, Nathan Nobbe wrote:
> > > On Wed, Apr 13, 2011 at 12:04 PM, Stuart Dallas <stuart@xxxxxxxx>
> wrote:
> > > > > On Wednesday, 13 April 2011 at 18:55, Nathan Nobbe wrote:
> > > > > On Wed, Apr 13, 2011 at 11:49 AM, Jim Giner <
> jim.giner@xxxxxxxxxxxxxxxxxx>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.
>
The irony here is I've developed this rule of thumb by working with groups
that don't consider it a bad practice but should have.
> > > > 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?!
>
lol, i figured id give it a shot.
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.
I see what you're saying, but then you're implying that it's ideal to copy
the values into secondary data structure(s), perhaps modifying the values
along the way or at least have them accessed indirectly after the initial
processing.
> 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.
>
is that written in stone?
The arbitrary array i spoke of in my initial post was misleading. I advised
it because there are two sources of data going into the same template.
Having an abstraction for the template allows assumptions about it, like
perhaps more than one client is invoking this template. Having it accept
$_POST would also naturally impose a presumption that the data is strictly
provided by the application client (or the server passing data forward to
itself through subsequent client requests). However that sort of overcast
my opinion on reading $_POST and that is, why not. Go ahead, let code read
it anywhere as long as the code is taking precautions. If there's code that
handles sanitization centrally then there's no need to access $_POST
directly because the sanitization has already been performed and you're just
wasting cycles doing it another time.
The main point about writing arbitrary data to the array is a matter of
organization, not technical limitations. Looking at the definition on the
manual:
An associative array of variables passed to the current script via the HTTP
POST method.
Well that doesn't sound like a good place for a mysql_insert_id, but you
could put one in there (read on).
> > 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.
>
Yup, an appreciation of the value this list has to offer and the
shortcomings of limited advice.
> > > 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.
>
I could put my groceries in the engine bay to take them home, but I'd rather
put them in the trunk.
> > > > 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.
>
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.
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..
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!
The only real value I see to setting values in the $_REQUEST et al arrays is
unit testing.
-nathan
