Re: [PHP] $_POST vars
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: 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.comwrote: 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
Re: [PHP] $_POST vars
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?
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-datacontentreal-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
Re: [PHP] $_POST vars
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.
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-datacontentreal-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.
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.
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.
-nathan
Re: [PHP] $_POST vars
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-datacontentreal-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
Re: [PHP] $_POST vars
Guys - the problem has been solved. Give it a rest. (sent only to the list) (remainder deleted for the benefit of all :) ) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] $_POST vars
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. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vars
On Wednesday, 13 April 2011 at 18:49, Jim Giner 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. $_POST is a standard PHP array, with the only added feature being that it's available everywhere (i.e. it's a superglobal). There is nothing stopping you modifying that array from anywhere within your code. -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
Re: [PHP] $_POST vars
On Wed, Apr 13, 2011 at 1:49 PM, Jim Giner jim.gi...@albanyhandball.comwrote: 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. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php I'm not sure what you're asking, but you can set the values of the POST array directly within a script, for instance: $_POST['new_key'] = 'new_value'; Adam -- Nephtali: A simple, flexible, fast, and security-focused PHP framework http://nephtaliproject.com
Re: [PHP] $_POST vars
On Wed, Apr 13, 2011 at 11:49 AM, Jim Giner jim.gi...@albanyhandball.comwrote: 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. -nathan
Re: [PHP] $_POST vars
On Wednesday, 13 April 2011 at 18:56, Jim Giner wrote: And that includes adding entirely new elements in that array? Yes, it's a standard array. It's not special other than being a superglobal. Do you have any suggestion on how to get the results of a query into POST easily or is it simply a for loop? Not sure what you mean by the results of a query. If you mean an array that you got from a MySQL query (my best guess), then simply assign that array to $_POST and Bob's your slightly perverted uncle! And please include the list when replying so everyone can benefit from the discussion. -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
RE: [PHP] $_POST vars
Hi Jim,
Sure you can create set of et of $_POST vars :
e.g.
form action=myphpaction.php method=POST
input type=password name=admin_code value='Enter here..'
onclick=if(this.value=='Enter here..'){this.value='';
this.style.color='#000'}
onblur=if(this.value==''){this.value='Enter here..';
this.style.color='#555'} /
input type=submit VALUE=Execute /
/form
So that admin_code var is passed to myphpaction.php as post and shall be
access there via $_POST[admin_code ];
However, note that in PHP all the output buffer is flushed actually,
ONLY after the script execution is terminated.
Skype: eliorr.com
-Original Message-
From: Jim Giner [mailto:jim.gi...@albanyhandball.com]
Sent: Wednesday, April 13, 2011 8:50 PM
To: php-general@lists.php.net
Subject: [PHP] $_POST vars
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.
--
PHP General Mailing List (http://www.php.net/) To unsubscribe, visit:
http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vars
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.comwrote: 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. 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. All hail the superglobals! (sarcasm for those not familiar) -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
Re: [PHP] $_POST vars
When you say assign that array to $_POST do you mean $_POST = $qrslt; Not sure about this assigning an array thing. - Original Message - From: Stuart Dallas stu...@3ft9.com Newsgroups: php.general To: Jim Giner jim.gi...@albanyhandball.com Cc: PHP General php-general@lists.php.net Sent: Wednesday, April 13, 2011 1:59 PM Subject: Re: [PHP] $_POST vars Not sure what you mean by the results of a query. If you mean an array that you got from a MySQL query (my best guess), then simply assign that array to $_POST ... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vars
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. 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 :) 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. -nathan
Re: [PHP] $_POST vars
No need to email me AND send to the list. Is that the standard practice on this forum? Not encountered it before. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vars
Shrug, it's called reply-all and it's been brought up here before :) -nathan On Wed, Apr 13, 2011 at 12:25 PM, Jim Giner jim.gi...@albanyhandball.comwrote: No need to email me AND send to the list. Is that the standard practice on this forum? Not encountered it before.
Re: [PHP] $_POST vars
On Wednesday, 13 April 2011 at 19:12, Jim Giner wrote: When you say assign that array to $_POST do you mean $_POST = $qrslt; Not sure about this assigning an array thing. Yup, nothing more complicated than that. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ - Original Message - From: Stuart Dallas stu...@3ft9.com Newsgroups: php.general To: Jim Giner jim.gi...@albanyhandball.com Cc: PHP General php-general@lists.php.net Sent: Wednesday, April 13, 2011 1:59 PM Subject: Re: [PHP] $_POST vars Not sure what you mean by the results of a query. If you mean an array that you got from a MySQL query (my best guess), then simply assign that array to $_POST ... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vars
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.comwrote: 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. 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. My response to the OP was simply answering the question. 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. 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? -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
Re: [PHP] $_POST vars
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.comwrote: 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... 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. 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. 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. 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. -nathan
Re: [PHP] $_POST vars
PHP then is Truly an amazing and powerful language. I can expand the contents of the array $_POST by simply assigning a separate arry to it. Obviously if I have a duplicate element-name in my array it will override the $_POST element but that's my problem. Stuart Dallas stu...@3ft9.com wrote in message news:4962044e8a244fc28719d97746759...@3ft9.com... On Wednesday, 13 April 2011 at 19:12, Jim Giner wrote: When you say assign that array to $_POST do you mean $_POST = $qrslt; Not sure about this assigning an array thing. Yup, nothing more complicated than that. -Stuart (remainder deleted for everyone's sake :) ) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vars
Nathan Nobbe quickshif...@gmail.com wrote on 04/13/2011 12:47:11 PM: [much snippage] 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 like Chris Shiflett's approach, which emphasizes security. Step 1 with posted (tainted) data is to sanitize it. Clean values are then moved from $_GET/$_POST into a new array, e.g., $CLEAN, so that it is immediately clear to code reviewers, future support programmers, etc., that the data is now clean and safe to use. With this approach, $_POST is only used at Step 1 and then disappears from the remaining code; $CLEAN is used in subsequent steps. Using $_POST out in the middle of nowhere *looks* like it could be a security flaw, whether it actually is or isn't. And you know how Joel Spolsky feels about code that *looks* like it could be an error ;) But, yes, you can use $_POST just like any other array. Not a practice I prefer, but YMMV. Kirk
Re: [PHP] $_POST vars
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.comwrote: 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
Re: [PHP] $_POST- Vars - Back-Button
On Wed, August 1, 2007 6:18 am, Christian Hänsel wrote: this might be a noob- question, but I simply do not care anymore. After a few hours of fiddling with this @/**%$ (screaming AAa), I would like to ask you. So what I have is this: I have a search engine for a car market, which has about 30 $_POST- vars. Now when the user clicks on a result link, it takes him to the car details page. Now when he hits the back button, he either gets the Page has expired (IE) or the Wanna send the form data again message box (FF). Now I would like to have kind of a back-button, so the user will see the reusult list again without having to deal with this. I guess what I'm asking for is a one-click re-submission of POST data... Do you have a clue on how to do this? The EASIEST solution would be to change your POST to GET, assuming you are NOT changing any data with the search. -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] $_POST- Vars - Back-Button
Hi guys, this might be a noob- question, but I simply do not care anymore. After a few hours of fiddling with this @/**%$ (screaming AAa), I would like to ask you. So what I have is this: I have a search engine for a car market, which has about 30 $_POST- vars. Now when the user clicks on a result link, it takes him to the car details page. Now when he hits the back button, he either gets the Page has expired (IE) or the Wanna send the form data again message box (FF). Now I would like to have kind of a back-button, so the user will see the reusult list again without having to deal with this. I guess what I'm asking for is a one-click re-submission of POST data... Do you have a clue on how to do this? Cheers for any answers! Chris -- - My baby's first words will be Hello World -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST- Vars - Back-Button
Hey Chris, 1) Use sessions (read up on it if you don't know it; in short: session_start() at the very beginning of your script creates a $_SESSION array that is persistent through subsequent page calls) 2) Submit the form to the search page and preprocess it by putting the post vars into the session, then use header() to relocate to the actual processor 3) Have the actual processor work, i.e. the result list page script, with the session data. Do not destroy the session data afterwards. Now if a user uses the back-button from your result list, he will again reach the search page, without the 'wanna send form again' message box. I very strongly advise you not to break the browsers back button functionality. It's there for a reason and people rely on it to behave accordingly. Don't duplicate functionality that the browser already has. HTH, Stijn Christian Hänsel schreef: Hi guys, this might be a noob- question, but I simply do not care anymore. After a few hours of fiddling with this @/**%$ (screaming AAa), I would like to ask you. So what I have is this: I have a search engine for a car market, which has about 30 $_POST- vars. Now when the user clicks on a result link, it takes him to the car details page. Now when he hits the back button, he either gets the Page has expired (IE) or the Wanna send the form data again message box (FF). Now I would like to have kind of a back-button, so the user will see the reusult list again without having to deal with this. I guess what I'm asking for is a one-click re-submission of POST data... Do you have a clue on how to do this? Cheers for any answers! Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST- Vars - Back-Button
this might be a noob- question, but I simply do not care anymore. After a few hours of fiddling with this @/**%$ (screaming AAa), I would like to ask you. So what I have is this: I have a search engine for a car market, which has about 30 $_POST- vars. Now when the user clicks on a result link, it takes him to the car details page. Now when he hits the back button, he either gets the Page has expired (IE) or the Wanna send the form data again message box (FF). Now I would like to have kind of a back-button, so the user will see the reusult list again without having to deal with this. I guess what I'm asking for is a one-click re-submission of POST data... Do you have a clue on how to do this? The resubmit page is being displayed because the results page is the result of a form POST. You can do one of two things: 1. Change your search form to a GET request. 2. Stuff the existing POST data into the session and have your results page use that before looking to the POST data. -- Richard Heyes +44 (0)844 801 1072 http://www.websupportsolutions.co.uk Knowledge Base and HelpDesk software that can cut the cost of online support -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] $_POST vars problem
I just changed my server to SSL, everything worked before that. now if I
have a form with an input box (named searchstring for example) with a
value of TEST, when that form is posted (submitted) I get the following:
foreach($_POST as $key = $value) {
echo [POST]Key: '$key'; Value: '$value'br\n;
}
will print:
Key:'searchstring' ; Value: 'TESTsearchstring=TEST'
can anyone tell me where the second searchstring=TEST is coming from? I
have tried register globals on and off.
[EMAIL PROTECTED]
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vars problem
--- Kenneth Brill [EMAIL PROTECTED] wrote: can anyone tell me where the second searchstring=TEST is coming from? I have tried register globals on and off. Can you also show us the HTML for your form on the previous page? The simplest test case that produces this problem would be best. Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vars problem
I will try to shortly. The server in question is password protected and has lot of information I don;t need hacked into right now. I'll set up a limited short term account and post everything then. On another note, I have found that if I include (and use) the submit button everything works perfectly, HOWEVER if I just enter data and hit return then it messes up. That make no sence to me but maybe someone out there can put it together. thanks Chris Shiflett [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... --- Kenneth Brill [EMAIL PROTECTED] wrote: can anyone tell me where the second searchstring=TEST is coming from? I have tried register globals on and off. Can you also show us the HTML for your form on the previous page? The simplest test case that produces this problem would be best. Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] $_POST vars problem
--- Kenneth Brill [EMAIL PROTECTED] wrote: I will try to shortly. The server in question is password protected and has lot of information I don;t need hacked into right now. I'll set up a limited short term account and post everything then. So you do not have access to the server that has the code you are trying to debug? That seems like a bigger problem. If you can at least test this with a browser, you can use it to view the source. This will reveal the HTML, and you can just show us the relevant parts. Of course, if we notice the problem, it sounds like it is useless anyway, since you cannot access the server to fix anything. Unless I am missing something... Chris On another note, I have found that if I include (and use) the submit button everything works perfectly, HOWEVER if I just enter data and hit return then it messes up. That make no sence to me but maybe someone out there can put it together. thanks Chris Shiflett [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... --- Kenneth Brill [EMAIL PROTECTED] wrote: can anyone tell me where the second searchstring=TEST is coming from? I have tried register globals on and off. Can you also show us the HTML for your form on the previous page? The simplest test case that produces this problem would be best. Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] $_POST vars problem
-Original Message-
From: Kenneth Brill [mailto:[EMAIL PROTECTED]]
Sent: 20 January 2003 15:53
I just changed my server to SSL, everything worked before
that. now if I
have a form with an input box (named searchstring for
example) with a
value of TEST, when that form is posted (submitted) I get
the following:
foreach($_POST as $key = $value) {
echo [POST]Key: '$key'; Value: '$value'br\n;
}
will print:
Key:'searchstring' ; Value: 'TESTsearchstring=TEST'
If you're using Apache 2, I suggeest you browse on over to this bug report:
http://bugs.php.net/bug.php?id=18648. (Well, maybe you want to go take a
look there anyway, as it's definitely concerning this very behaviour.)
Cheers!
Mike
-
Mike Ford, Electronic Information Services Adviser,
Learning Support Services, Learning Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Beckett Park, LEEDS, LS6 3QS, United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] $_POST vars problem
On another note, I have found that if I include (and use) the submit button everything works perfectly, HOWEVER if I just enter data and hit return then it messes up. You could try including a hidden submit field like this: input type=hidden name=submit value=1 For name=submit change that to whatever name your normal submit button has and you'll find that a submit is set even if you hit return instead of clicking on the submit button. It may or may not resolve the issues you're seeing but it can help general form processing anyway. CYA, Dave -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
