Why use param_post(‘value’) ?
I am guessing by the code this is a different way of writing $_POST[‘value’], but I cant find any documentation on it. Can any one tell me what the differnce is or why you would NOT just use $_POST ?
Thank you,
James
param_post(‘value’) is not PHP itself but some framework probably.
Guess I should grep’d first asked later
function param_get($key) {
if (array_key_exists($key, $_GET)) {
return $_GET[$key];
}
else {
return '';
}
}
function param_post($key) {
if (array_key_exists($key, $_POST)) {
return $_POST[$key];
}
else {
return '';
}
}
maybe they got sick of seeing the warrning because a value wasnt set?
It was driving me crazy because its every where through out the site
Thank you though
That’s actually not the best way to check for a GET/POST key. It’s better to use the isset() function.
I think perhaps stating why the above is true would help: the primary reason being “isset() does not return TRUE for array keys that correspond to a NULL value, while array_key_exists() does”, as stated in the PHP manual. It is possible to have a null value in a post.
The only time when there will be a NULL value in the $_POST data is if you’re trying to check the value of a non-existent key. And if that’s the case, then both isset() and array_key_exists() will return false. If a valid key is entered then they’ll both return true. I’d personally go with isset() (a language construct; not a function, Force Flow) because it’s the faster option; but they’re both valid ways of achieving the same result.
Valid point, but consider the following: user is developing using test driven design, had coded up his form processing classes, but not the html. When he gets to the html, he forgets a field, or some process prior to validation sets a value to null (you’d be surprised how often this happens in early development). The isset construct would catch them both, while array_key_exists would only catch one.
In any regard, I think the OP has the info he needs now. =)
Thanks guys I see your point with th enull value, but I do have one more question.
Is there anything really wrong with:
if($_POST[“value”]){code here}
or
if(!$_POST[“value”]){code here}
I know you will get the value not defined error, if you have errors (or in error_log) displaying, but I haven’t run into an issue where it hasnt worked as I expected it to.
Your example code only evaluates for true or not true. It doesn’t check to see if the array key exists. If it doesn’t, you’ll get an error. The best practice is to first check if the key exists, then filter/sanitize, then evaluate it.
if(isset($_POST['value'])){ //check if the key exists
$value=preg_replace('©[^a-zA-Z0-9]©', ' ', $str); //this sanitizes by removing everything except numbers and letters. This is just an example. You'll probably want to do something different depending upon the input you're looking for.
if($value=="something"){ //evaluate the value
//do something
}
}
unless i am catching the checkboxes from a form I am almost always looking for true or false, if i am looking for something like checkboxes i would do something like
if($_POST[“value”]){
if(is_array($_POST[“value”])){
do my foreach
}else{
do whatever if its only 1 value
}
}
is there anything wrong with that?
That depends. Is your product skinnable? If so, consider that a consumer may reskin that particular html to use something other than check-boxes. We’ve pretty much gone over every facet of why that general coding style isn’t the best solution, but if you go that route, you might want to wrap that bit of code into a single recursive method.
Why not simply use
$param = @$_POST['value'];
?
I know error suppressing should be avoided but in this simple case it’s clear that the param_post() function does nothing else but suppresses any potential notice errors, if it were not for the notice errors this function would make no sense. Then why not use the native shorter and simpler syntax?
I know that @$_POST[‘value’] will return null instead of an empty string if the value is not set but then you can do this:
$param = (string) @$_POST['value'];
It’s poor practice to suppress errors without a very good reason. This isn’t a very good reason because there are already standard approaches for handling these kinds of variables.
Certainly there are other approaches but I’m specifically comparing error suppression to the param_post() function presented in this thread. When you look at what that function does then it’s nothing else but suppress errors with if statements instead of the @ character. For me this is just a syntactic difference so I can as well use the shorter @ syntax.
And it’s not only about $_POST and $_GET, I may want to check other arrays as well:
$type = isset($options['categories']['type']) ? $options['categories']['type'] : null;
When I need to do the above I may also do this and save myself some typing:
$type = @$options['categories']['type'];
Both of these statements do the same thing, they avoid the error when the key doesn’t exist and I can’t think of a scenario where their result would be different.
$_POST = array_merge( array_fill_keys( array( 'expected-field-1', 'expected-field-2' ), null ), $_POST );
if ( $_POST['expected-field-1'] )
//...
There gets ride of error suppression while not checking for the existence of the array key before use. Instead, defining the fields that you expect to exist in the array using null as a default value. Relying on, PHP to return a null value it is an undefined behavior and you should not rely on it, it can change at any time.
This is an interesting idea. I like that the expected fields are enumerated in the code, it’s like self-documenting code.
However, the syntax looks a bit convoluted to me. How about a simpler version, this should also work:
$_POST += array_fill_keys(array('expected-field-1', 'expected-field-2'), null);
or this:
$_POST += array(
'expected-field-1' => null,
'expected-field-2' => null,
);
That would not work, Lemon. Without merge you would overwrite the existing keys that you want with null.
That’s incorrect. With your latter code snippet, you don’t avoid the parser giving out the error, you just suppress it so that the error doesn’t show. This is not only a rather lazy way to code, but you’re also wasting resources by making the script have to throw the error, and then having to suppress the error being thrown (a flagrant waste of overhead resource usage). I would advise you not to be lazy with the code you’re producing, and to make it as error free as possible.
Well, for me being lazy in coding is a positive trait because it means less work. Of course, provided I don’t get into trouble in the future because of this laziness - and in this case I can see no trouble whatsoever.
You are technically right but I don’t have to be interested that much what php is doing under the hood, the behaviour and effect of both of these statements is exactly the same and introduces no problem to my application.
I may try to test the performance and memory usage differences but unless I’m using @ in a long loop I don’t have to care about the microseconds. What’s more, in a normally running web application all those expected array keys are there so no error suppression occurs. So that waste of resource usage you are talking about occurs very rarely.
I generally agree with being against @ but I have no problem with it for assigning variables if used outside a loop.