SitePoint Sponsor

User Tag List

Results 1 to 20 of 20
  1. #1
    SitePoint Enthusiast
    Join Date
    Nov 2011
    Location
    Florida
    Posts
    58
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)

    Why param_post('value') ?

    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
    Last edited by JamesKenny; Sep 7, 2012 at 20:00. Reason: aweful spelling

  2. #2
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    param_post('value') is not PHP itself but some framework probably.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  3. #3
    SitePoint Enthusiast
    Join Date
    Nov 2011
    Location
    Florida
    Posts
    58
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    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

  4. #4
    Barefoot on the Moon! silver trophy Force Flow's Avatar
    Join Date
    Jul 2003
    Location
    Northeastern USA
    Posts
    4,615
    Mentioned
    56 Post(s)
    Tagged
    1 Thread(s)
    That's actually not the best way to check for a GET/POST key. It's better to use the isset() function.
    Visit The Blog | Follow On Twitter
    301tool 1.1.5 - URL redirector & shortener (PHP/MySQL)
    Can be hosted on and utilize your own domain

  5. #5
    Resident OCD goofball! bronze trophy Serenarules's Avatar
    Join Date
    Dec 2002
    Posts
    1,911
    Mentioned
    26 Post(s)
    Tagged
    0 Thread(s)
    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.

  6. #6
    SitePoint Zealot
    Join Date
    Feb 2012
    Location
    United Kingdom
    Posts
    110
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Serenarules View Post
    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.

  7. #7
    Resident OCD goofball! bronze trophy Serenarules's Avatar
    Join Date
    Dec 2002
    Posts
    1,911
    Mentioned
    26 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by modernW View 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. =)

  8. #8
    SitePoint Enthusiast
    Join Date
    Nov 2011
    Location
    Florida
    Posts
    58
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    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.

  9. #9
    Barefoot on the Moon! silver trophy Force Flow's Avatar
    Join Date
    Jul 2003
    Location
    Northeastern USA
    Posts
    4,615
    Mentioned
    56 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by JamesKenny View Post
    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.

    Code:
    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
    	}
    }
    Visit The Blog | Follow On Twitter
    301tool 1.1.5 - URL redirector & shortener (PHP/MySQL)
    Can be hosted on and utilize your own domain

  10. #10
    SitePoint Enthusiast
    Join Date
    Nov 2011
    Location
    Florida
    Posts
    58
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    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?

  11. #11
    Resident OCD goofball! bronze trophy Serenarules's Avatar
    Join Date
    Dec 2002
    Posts
    1,911
    Mentioned
    26 Post(s)
    Tagged
    0 Thread(s)
    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.

  12. #12
    SitePoint Guru bronze trophy
    Join Date
    Dec 2003
    Location
    Poland
    Posts
    930
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    Why not simply use
    PHP Code:
    $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:

    PHP Code:
    $param = (string) @$_POST['value']; 

  13. #13
    Barefoot on the Moon! silver trophy Force Flow's Avatar
    Join Date
    Jul 2003
    Location
    Northeastern USA
    Posts
    4,615
    Mentioned
    56 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by Lemon Juice View Post
    Why not simply use
    PHP Code:
    $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:

    PHP Code:
    $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.
    Visit The Blog | Follow On Twitter
    301tool 1.1.5 - URL redirector & shortener (PHP/MySQL)
    Can be hosted on and utilize your own domain

  14. #14
    SitePoint Guru bronze trophy
    Join Date
    Dec 2003
    Location
    Poland
    Posts
    930
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Force Flow View Post
    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:
    PHP Code:
    $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:
    PHP Code:
    $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.

  15. #15
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    PHP Code:
    $_POST array_mergearray_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.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  16. #16
    SitePoint Guru bronze trophy
    Join Date
    Dec 2003
    Location
    Poland
    Posts
    930
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    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:
    PHP Code:
    $_POST += array_fill_keys(array('expected-field-1''expected-field-2'), null); 
    or this:
    PHP Code:
    $_POST += array(
      
    'expected-field-1' => null,
      
    'expected-field-2' => null,
    ); 

  17. #17
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    That would not work, Lemon. Without merge you would overwrite the existing keys that you want with null.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  18. #18
    SitePoint Guru bronze trophy
    Join Date
    Dec 2003
    Location
    Poland
    Posts
    930
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    I think it will work - check it out! The union operator does not overwrite existing keys.

  19. #19
    SitePoint Zealot
    Join Date
    Feb 2012
    Location
    United Kingdom
    Posts
    110
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Lemon Juice View Post
    PHP Code:
    $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:
    PHP Code:
    $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.
    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.

  20. #20
    SitePoint Guru bronze trophy
    Join Date
    Dec 2003
    Location
    Poland
    Posts
    930
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by modernW View Post
    This is not only a rather lazy way to code,
    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.

    Quote Originally Posted by modernW View Post
    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).
    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.


Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •