SitePoint Sponsor

User Tag List

Results 1 to 25 of 25
  1. #1
    SitePoint Addict
    Join Date
    Nov 2009
    Posts
    284
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    if($var) vs. if(isset($var))

    Hi,

    When checking whether the submit button is pressed or not,

    if I use

    PHP Code:
    if (isset($_POST['submit'])) 
    it works fine. If I use

    PHP Code:
    if ($_POST['submit']) 
    it gives an "Undefined index" notice, which means I need isset() for this check.

    When checking whether the username and password fields are empty or not, both of the following works fine.

    PHP Code:
    if (isset($_POST['username']) && isset($_POST['password'])) 
    PHP Code:
    if ($_POST['username'] && $_POST['password']) 
    which means I don't need isset() for this check.

    My question is, should I always use isset() for checking variables or is it ok not to use it where it is not required?

  2. #2
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    4,813
    Mentioned
    141 Post(s)
    Tagged
    0 Thread(s)
    isset() doesn't check against empty, rather it checks whether or not the variable is set (or array index/key is set).

    To test against empty, you really should use empty()
    Be sure to congratulate xMog on earning April's Member of the Month
    Go ahead and blame me, I still won't lose any sleep over it
    My Blog | My Technical Notes

  3. #3
    Keeper of the SFL StarLion's Avatar
    Join Date
    Feb 2006
    Location
    Atlanta, GA, USA
    Posts
    3,747
    Mentioned
    64 Post(s)
    Tagged
    0 Thread(s)
    if($var)

    If $var is 0; this is false.
    If $var is "false", this is true.

    Proper coding should never use if($var). if(!isset($var)), if(empty($var)), if ($var === FALSE)....

    Now, as to your specific query, as cpradio has said, isset doesnt check for emptyness.

    Text Fields in a form are -ALWAYS- sent, even if they contain nothing.
    Thus, the variable $_POST['username'] will always be set when the form is submitted, but may contain nothing.
    Never grow up. The instant you do, you lose all ability to imagine great things, for fear of reality crashing in.

  4. #4
    SitePoint Wizard silver trophybronze trophy Cups's Avatar
    Join Date
    Oct 2006
    Location
    France, deep rural.
    Posts
    6,869
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by nayen View Post
    Hi,

    When checking whether the submit button is pressed or not,

    if I use

    PHP Code:
    if (isset($_POST['submit'])) 
    IIRC, this will only work if the user submitted the form by pressing the Submit button (although only an IE peculiarity I think).

    A user can submit a form by just pressing Enter on the keyboard so therefore you cannot be guaranteed the form submission will be caught.

    I find there is usually a form element which must always contain something, an email address field maybe.

    I generally enforce that this does at least contain something on the client, but of course js can be turned off.

    PHP Code:
    if( !strlen($_POST['email']) ){
    // a check like this can work as confirmation that the
    // form was not submitted or at least a key element 
    // was missed, so you cannot continue, so tell the user
    // fail here
    }

    // otherwise presume the form was indeed submitted 
    What do others think of this method?
    Last edited by Cups; Oct 22, 2012 at 07:20. Reason: add first line of comment

  5. #5
    SitePoint Addict
    Join Date
    Nov 2009
    Posts
    284
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by cpradio View Post
    isset() doesn't check against empty, rather it checks whether or not the variable is set (or array index/key is set).

    To test against empty, you really should use empty()
    Thanks, I will be using empty() from now on.

    Quote Originally Posted by StarLion View Post
    if($var)

    If $var is 0; this is false.
    If $var is "false", this is true.
    I am not sure if I clearly understood your example. The following two code blocks have the same output (bad):

    PHP Code:
    <?php
    $var 
    0;
    if (
    $var) {
        echo 
    'good';
    } else {
        echo 
    'bad';
    }
    ?>
    PHP Code:
    <?php
    $var 
    FALSE;
    if (
    $var) {
        echo 
    'good';
    } else {
        echo 
    'bad';
    }
    ?>
    Quote Originally Posted by StarLion View Post
    Proper coding should never use if($var). if(!isset($var)), if(empty($var)), if ($var === FALSE)....
    Thanks for the suggestion, I am just trying to learn the real "why"s so that I will not just copy & paste code from here or there but I will know the reasoning behind it.

    Quote Originally Posted by Cups View Post
    IIRC, this will only work if the user submitted the form by pressing the Submit button (although only an IE peculiarity I think).

    A user can submit a form by just pressing Enter on the keyboard so therefore you cannot be guaranteed the form submission will be caught.
    Sorry, what does IIRC mean? I tried submitting the form by pressing enter on all browsers and it worked as it should. Maybe it is an issue with previous IE versions?

  6. #6
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    4,813
    Mentioned
    141 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by StarLion View Post
    Proper coding should never use if($var). if(!isset($var)), if(empty($var)), if ($var === FALSE)....
    Was this meant to say never use if($var), but instead use isset, empty, === or !==? Just curious, as I first read it as never use if($var) or !isset(), empty(), or === FALSE and I mentally went WTF? Never heard that before... maybe I misread it.

    Quote Originally Posted by nayen View Post
    I am not sure if I clearly understood your example. The following two code blocks have the same output (bad):
    That is a conflict between FALSE and "FALSE" (being a string). The point is, your condition will be glitchy because of the automatic type conversion PHP runs on your variables. That is why it is recommended to use isset(), empty(), and identical comparison (=== or !==)

    I strongly encourage looking at the tables on http://www.php.net/manual/en/types.comparisons.php
    It will help show you how using a loose comparison could skew your expectations (same with using if($x)).

    PHP Code:
    <?php
    $var 
    0;
    if (
    $var) { // should echo "bad"
        
    echo 'good';
    } else {
        echo 
    'bad';
    }
    ?>
    PHP Code:
    <?php
    $var 
    "FALSE";
    if (
    $var) { // should echo "good"
        
    echo 'good';
    } else {
        echo 
    'bad';
    }
    ?>
    Be sure to congratulate xMog on earning April's Member of the Month
    Go ahead and blame me, I still won't lose any sleep over it
    My Blog | My Technical Notes

  7. #7
    SitePoint Addict
    Join Date
    Nov 2009
    Posts
    284
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by cpradio View Post
    That is a conflict between FALSE and "FALSE" (being a string). The point is, your condition will be glitchy because of the automatic type conversion PHP runs on your variables. That is why it is recommended to use isset(), empty(), and identical comparison (=== or !==)

    I strongly encourage looking at the tables on http://www.php.net/manual/en/types.comparisons.php
    It will help show you how using a loose comparison could skew your expectations (same with using if($x)).
    Thanks a lot, I will read it. I know that logical FALSE and string "FALSE" are two different things but I agree with your point.

  8. #8
    Keeper of the SFL StarLion's Avatar
    Join Date
    Feb 2006
    Location
    Atlanta, GA, USA
    Posts
    3,747
    Mentioned
    64 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by cpradio View Post
    Was this meant to say never use if($var), but instead use isset, empty, === or !==? Just curious, as I first read it as never use if($var) or !isset(), empty(), or === FALSE and I mentally went WTF? Never heard that before... maybe I misread it.
    This is why punctuation is important. Note the . after the first statement, and the ,'s following. It's meant to read as never use if($var). Instead use ....

    I strongly encourage looking at the tables on http://www.php.net/manual/en/types.comparisons.php
    It will help show you how using a loose comparison could skew your expectations (same with using if($x)).
    http://php.net/manual/en/language.ty...oolean.casting also a good read for IF's.
    Never grow up. The instant you do, you lose all ability to imagine great things, for fear of reality crashing in.

  9. #9
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    4,813
    Mentioned
    141 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by StarLion View Post
    This is why punctuation is important. Note the . after the first statement, and the ,'s following. It's meant to read as never use if($var). Instead use ....
    Off Topic:

    That's exactly why I had to re-read it; I was certain that couldn't be what you were implying
    Be sure to congratulate xMog on earning April's Member of the Month
    Go ahead and blame me, I still won't lose any sleep over it
    My Blog | My Technical Notes

  10. #10
    SitePoint Wizard silver trophybronze trophy Cups's Avatar
    Join Date
    Oct 2006
    Location
    France, deep rural.
    Posts
    6,869
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by nayen View Post
    Sorry, what does IIRC mean? I tried submitting the form by pressing enter on all browsers and it worked as it should. Maybe it is an issue with previous IE versions?
    If I Recall Correctly, which possibly I have not

    Anyhow, checking for the existence of 'submit' is a habit I got out of using. Have I been mistaken all this time I wonder? ...

  11. #11
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    4,813
    Mentioned
    141 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Cups View Post
    Anyhow, checking for the existence of 'submit' is a habit I got out of using. Have I been mistaken all this time I wonder? ...
    Not mistaken, maybe just a bit of over-exaggerated? http://www.dev-archive.net/articles/...t-buttons.html

    Looks like the issue primarily pertains to using the button element for submitting a form instead of input with a type of submit.
    Be sure to congratulate xMog on earning April's Member of the Month
    Go ahead and blame me, I still won't lose any sleep over it
    My Blog | My Technical Notes

  12. #12
    SitePoint Wizard silver trophybronze trophy Cups's Avatar
    Join Date
    Oct 2006
    Location
    France, deep rural.
    Posts
    6,869
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)
    Yes, in typical fashion I probably pruned much of the detail away in my mind and ended up with a shorthand version stuck away in a dusty cupboard in my brain. Don't rely on 'submit'.

  13. #13
    SitePoint Guru bronze trophy
    Join Date
    Dec 2003
    Location
    Poland
    Posts
    925
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by StarLion View Post
    Proper coding should never use if($var). if(!isset($var)), if(empty($var)), if ($var === FALSE)....
    What's wrong with if($var)? It's a very nice shorthand and a very convenient one provided you are aware how it functions.

    if($var) is equivalent to if (!empty($var))
    if(!$var) is equivalent to if (empty($var))

    the only difference being that empty() will not issue notice errors in $var is not set. For exampe:
    PHP Code:
    // get array of products
    $var getProducts();

    if (
    $var) {
      
    // ...

    This is an easy check whether $var array has any elements. In the same way, you can check whether a function/method returned an object as expected or null/false. Less typing and very convenient.

    It's only important to be cautious about using if($var) on strings and numbers.

    For checking if a form text field has been filled in this is good:
    PHP Code:
    if (isset($_POST['var']) && is_string($_POST['var']) && $_POST['var'] !== ''

  14. #14
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    4,813
    Mentioned
    141 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Lemon Juice View Post
    What's wrong with if($var)? It's a very nice shorthand and a very convenient one provided you are aware how it functions.

    if($var) is equivalent to if (!empty($var))
    if(!$var) is equivalent to if (empty($var))

    the only difference being that empty() will not issue notice errors in $var is not set. For exampe:
    PHP Code:
    // get array of products
    $var getProducts();

    if (
    $var) {
      
    // ...

    This is an easy check whether $var array has any elements. In the same way, you can check whether a function/method returned an object as expected or null/false. Less typing and very convenient.

    It's only important to be cautious about using if($var) on strings and numbers.

    For checking if a form text field has been filled in this is good:
    PHP Code:
    if (isset($_POST['var']) && is_string($_POST['var']) && $_POST['var'] !== ''
    Apart from the possibilities of getting results that were not expected, I find that using if ($var) is much harder to test. If you take a look at the link I posted back earlier, your tests would need to take into account all of the rows in the table.

    By explicitly saying isset(), is_string(), and !== '', you now know exactly what you need to test against and your readability just went up.
    Be sure to congratulate xMog on earning April's Member of the Month
    Go ahead and blame me, I still won't lose any sleep over it
    My Blog | My Technical Notes

  15. #15
    SitePoint Member
    Join Date
    Dec 2010
    Posts
    18
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    1) If you just need to check whether the page was opened via GET or POST method (clicking a link vs submitting a form) use this:

    PHP Code:
    if ($_SERVER["REQUEST_METHOD"] == "POST") {
    // process form

    2) isset() is not used to check the emptiness of a variable. It checks for the presence of a variable in the PHP symbol table. The presence of variable does not imply the variable contains a meaningful value. If the user submitted an EMPTY form then:

    PHP Code:
    if (isset($_POST['username']) && isset($_POST['password'])) // CONDITION PASSES SINCE BOTH VARIABLES ARE SET (BOTH CONTAIN EMPTY STRING OF COURSE)
    if ($_POST['username'] && $_POST['password']) // CONDITION FAILS BUT NOTICE IS NOT ISSUED 
    3) Now the recommended solution: use empty() function:

    PHP Code:
    if (! empty($_POST['username']) && ! empty($_POST['password'])) 
    // 1) NOTICE IS NOT ISSUED IF THE VARIABLE IS NOT PRESENT (see empty() documentation)
    // 2) BOTH VARIABLES MUST BE NON-EMPTY (0, "", NULL, false etc are considered empty) 

  16. #16
    Keeper of the SFL StarLion's Avatar
    Join Date
    Feb 2006
    Location
    Atlanta, GA, USA
    Posts
    3,747
    Mentioned
    64 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by cpradio View Post
    Apart from the possibilities of getting results that were not expected, I find that using if ($var) is much harder to test. If you take a look at the link I posted back earlier, your tests would need to take into account all of the rows in the table.

    By explicitly saying isset(), is_string(), and !== '', you now know exactly what you need to test against and your readability just went up.
    Not to mention that what production site are you working on that wants PHP E_NOTICE's thrown into their page?
    Never grow up. The instant you do, you lose all ability to imagine great things, for fear of reality crashing in.

  17. #17
    SitePoint Member
    Join Date
    Oct 2012
    Posts
    9
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I use something like this to check:
    if (isset($_POST['var']) && is_string($_POST['var']) && $_POST['var'] !== '') {
    ....
    }

  18. #18
    SitePoint Wizard silver trophybronze trophy Cups's Avatar
    Join Date
    Oct 2006
    Location
    France, deep rural.
    Posts
    6,869
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)
    I thought all POST values were strings, so a check for is_string() seems superfluous to me.

    If an empty string '' is a fail, I'd guess a space in a string would be just as useless ' '.

    A combination of a boolean check of strlen() and trim() be a bit more useful.

    PHP Code:
    $_POST['var'] = " 3 ";

    if (isset(
    $_POST['var']) && strlen(trim($_POST['var']))) {
    //....
    echo "var at least contained something other that a space ..." ;


    Occasionally though, you may want to run trim() again on a number of POST vars before say, storing in a db table, so given the same incoming you could use :

    PHP Code:
    $_POST['var'] = " 3 ";

    var_dump($_POST['var']);  // string (3) ' 3 '

    $_POST array_map'trim'$_POST);
    // now all your POST vars have been trimmed ...


    // now just check exists, and strlen is not 0
    if (isset($_POST['var']) && strlen($_POST['var'])) {
    //....
    echo "var at least contained something other that a space ..." ;
    var_dump($_POST['var']); // string (1) '3'



  19. #19
    SitePoint Guru bronze trophy
    Join Date
    Dec 2003
    Location
    Poland
    Posts
    925
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Cups View Post
    I thought all POST values were strings, so a check for is_string() seems superfluous to me.
    No! POST and GET values can also be arrays - when the input names contain square brackets - so is_string() is a very desirable validation check. I wouldn't want to run strlen() on an array or do any other string manipulations on a $var before knowing it is a string.

  20. #20
    SitePoint Wizard silver trophybronze trophy Cups's Avatar
    Join Date
    Oct 2006
    Location
    France, deep rural.
    Posts
    6,869
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)
    Thanks for correcting me then.

  21. #21
    Always A Novice bronze trophy
    K. Wolfe's Avatar
    Join Date
    Nov 2003
    Location
    Columbus, OH
    Posts
    2,079
    Mentioned
    53 Post(s)
    Tagged
    0 Thread(s)
    Set a Boolean variable in a session

    I only suggest doing this since I prefer to store the entire POST array in a session so that I can easily handle multiple HTTP requests with the users data for error checking and such.

  22. #22
    SitePoint Mentor bronze trophy
    John_Betong's Avatar
    Join Date
    Aug 2005
    Location
    City of Angels
    Posts
    1,578
    Mentioned
    62 Post(s)
    Tagged
    3 Thread(s)
    I know the thread title is about advantages or different variable testing but why not assume the userrname and password are correct, test for an exact match and report back on failure?

  23. #23
    Community Advisor silver trophybronze trophy
    dresden_phoenix's Avatar
    Join Date
    Jun 2008
    Location
    Madison, WI
    Posts
    2,734
    Mentioned
    31 Post(s)
    Tagged
    1 Thread(s)
    Much morle learned colleges have commented , but I feel I should clarify some things that were said.

    1) isset() checks for the EXISTENCE of the variable, regardless of its value.

    2) As StarL pointed out if($var) is risky ( tho I find it useful in controlled situations). ($var) will return TRUE if: $var is any # which is not equal to 0. if $var is BOOLEAN TRUE, if $var is NULL, or if it's and EMPTY string ( ' ' will cause ($var) to be TRUE, for example; but also note that '' is not == to ' ' , so trimming your sting before checking is a good idea. Still what kind of password is ' '?!?!).

    3) Learn about ALL type check functions. PHP doesn't rely on DECLARED var types so: $a='111'; $b=150; $c=$a+$b; $a is a STRING. $b and $c are INTEGERs, however. clever way to make sure text field is an integer: (is_integer($value+0).

    4) All text inputs (this include passwords) are submitted, even if not filled. AND they are all strings.


    So the issue here is more of logic than of which function or what syntax.

    1) Confirm that the form was FILLED AND SENT ( god help you if you are using $_GET for a secure info, BTW). It is good practice to do it via isset(name of submit button).
    2) Now you know that the user , at least, pressed submit on the form and did not get to this step via some other nefarious cleverness so (see point 4 above) you dont need to check if your pass and name fields are set.
    3) UNLESS you want to SPECIFY a "this field cannot be empty!" error to the user you dont need to worry about (!$var)
    4) This means that the only condition you need to check ( except maybe for special characters.. to prevent SQL injections) is ($var==$correctPass). it woulso be redundant to check the variable type of the pass or name as :
    i) a password check is NOT a math function so it is solely concerned wit the sequence of characters. For this purpose '1055'==1055, anyway
    ii) ANYWAY, text fields submit info as strings.. so all text fields will type as STRING , even if they are fully numeric


    so it boils down to this:
    Code:
    <?
    $FailEntry='';
    if (isset($_POST['submitButtonName'])){
        //other validation stuff.... 
        if ($theirPass != $rightPass){ $FailEntry="Acess Denied!!!";}
    }
    ?>
    <? if (!$FailEntry) :?>
    <? echo "<div>Welcome USER</div>";?>
    <? else : ?>
    <? echo "<div>FailEntry</div>";?>
    <!-- your form HTML--> 
    <? endif; ?>
    hope that helps.

  24. #24
    SitePoint Guru bronze trophy
    Join Date
    Dec 2003
    Location
    Poland
    Posts
    925
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dresden_phoenix View Post
    however. clever way to make sure text field is an integer: (is_integer($value+0).
    No, this doesn't check for an integer at all. Any string, boolean and even null will cause this condition to return true. Actually, this only checks for the (lack of) existence of a fractional part of a number. Moreover, it will result in a fatal error if $value is an array.

    Quote Originally Posted by dresden_phoenix View Post
    4) All text inputs (this include passwords) are submitted, even if not filled. AND they are all strings.
    As was mentioned earlier they can be arrays as well. And you can never be sure if they have really been submitted until you check it.

    Quote Originally Posted by dresden_phoenix View Post
    1) Confirm that the form was FILLED AND SENT ( god help you if you are using $_GET for a secure info, BTW). It is good practice to do it via isset(name of submit button).
    I don't think naming the submit button is necessary at all unless you want to target multiple submit buttons. Checking if a form was sent can be done with checking $_SERVER['REQUEST_METHOD'] or even the ugly but simple if($_POST) will do - $_POST is always set in PHP and it's an empty array for GET requests and also for POST requests without any fields (empty forms).

    Quote Originally Posted by dresden_phoenix View Post
    2) Now you know that the user , at least, pressed submit on the form and did not get to this step via some other nefarious cleverness so (see point 4 above) you dont need to check if your pass and name fields are set.
    No, you can't be sure about how the user got to this step and any malicious cleverness is possible, your previous check doesn't prove anything and you still need to check if fields are set - unless you are happy with NOTICE errors. The reason we do detailed checks for submitted values is that they all can be spoofed and you can potentially receive any combination of data. That's why all kinds of checks are necessary like isset(), is_string(), strlen(), etc.

    Quote Originally Posted by dresden_phoenix View Post
    4) This means that the only condition you need to check ( except maybe for special characters.. to prevent SQL injections) is ($var==$correctPass).
    Two things are incorrect in this reasoning - first there's no need to check for special characters to prevent SQL injections, if you have to do it then there's an underlying security problem in your application. A properly escaped value, or one passed via a prepared statement, is safe against SQL injections regardless of special characters. However, you may want to check for special characters not to allow some garbage data to get to your database.

    Second, ($var==$correctPass) is not enough since $var can be unset so you need to use isset().

    Quote Originally Posted by dresden_phoenix View Post
    it woulso be redundant to check the variable type of the pass or name as :
    i) a password check is NOT a math function so it is solely concerned wit the sequence of characters. For this purpose '1055'==1055, anyway
    If you really need to compare plain text passwords then you should use the === operator. Consider these passwords to be equal if used with ==:

    '000000' == '0'
    '000000' == '00.00'
    '000000' == '-0.0'
    '000000' == '+00.00'
    '12345' == '+000000012345.'

    Quote Originally Posted by dresden_phoenix View Post
    ii) ANYWAY, text fields submit info as strings.. so all text fields will type as STRING , even if they are fully numeric
    As mentioned earlier, they can be arrays and you never know if someone may misuse your form and send an array in a field that you expect to be a string. Or, the field may not be sent at all, too.

  25. #25
    SitePoint Mentor bronze trophy
    John_Betong's Avatar
    Join Date
    Aug 2005
    Location
    City of Angels
    Posts
    1,578
    Mentioned
    62 Post(s)
    Tagged
    3 Thread(s)
    @dresden_phoenix ;

    The point I was trying to make was testing on the off-chance for variable validity slows the login process.

    Maybe better to assume valid login details and return false with a message.

    PHP Code:
    # set variables
        
    $uname 'valid-name'#array(1,2,23); # 'valid-name';
        
    $pword 123456789 ;
        
    $error ''

    # pass variables and define result
        
    define('LOGGED_IN'login($uname$pword$error) );

    # show results
        
    echo LOGGED_IN ?  'LOGGED_IN' 'FAILED BECAUSE ' .$error;
        echo 
    '<br />$uname: '$uname;
        echo 
    '<br />$pword: '$pword;
        echo 
    '<br />$error: '$error

    //===============================================
    //
    //  useage -  login($uname, $pword, & $msg_by_ref); 
    //       
    //  return - true or false with and 'error message'
    //
    //===============================================
    function login($uname$pword, & $msg_by_ref 'dummy and not used')
    {
      
    $result = ($uname === 'valid-name')  && (123456789 === $pword);
      
      try
      { 
        if ( ! 
    $result)
        {
          
    #$err = 'FAILED THE FOLLOWING TESTS';
        
          
    if  (is_array($uname))        $err 'Its an array()'
          else if (
    is_string($uname))   $err 'String does not match'
          else if (
    is_bool($uname))     $err 'Its a boolean'
          else if(
    is_numeric($uname))
          {
            if      (
    $uname 0)    $err 'Its more than Zero'
            else if (
    $uname 0)    $err 'Its less than Zero'
            else                    
    $err 'Its ZERO'
          }
          else if (empty(
    $uname))   $err 'Its empty()'
          else 
            
    $err 'FAILED THE FOLLOWING TESTS';

          throw new 
    Exception($err);
          
        }
      } 
      catch( 
    Exception $e )
      {
         
    $result      false# heading($e->getMessage());
         
    $msg_by_ref  $e->getMessage();
      }
      
      return 
    $result;

    Last edited by John_Betong; Oct 30, 2012 at 02:57. Reason: formatting & spelling not my fortay, missed message


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
  •