Dynamic Drive Forums - Blogs - traq http://www.dynamicdrive.com/forums/blog.php?29708-traq Dynamic Drive help forum en Sun, 19 May 2013 01:01:39 GMT vBulletin 10 http://www.dynamicdrive.com/forums/images/misc/rss.jpg Dynamic Drive Forums - Blogs - traq http://www.dynamicdrive.com/forums/blog.php?29708-traq <![CDATA[HedgeClipper [part 2]!]]> http://www.dynamicdrive.com/forums/entry.php?275-HedgeClipper-part-2-! Mon, 21 Jan 2013 00:19:54 GMT Hey guys, I hope everyone has had a great start to the new year.

If you're just joining us, we're making hedgeclipper: a user log-in system. Last time, we outlined the basics of how hedgeclipper will work, and wrote a controller function for the whole thing. This time, we're going to focus on checking if the user is logged in or not. Before we start demanding a username and password, we're going to check if our user already logged in on a previous page visit. Have a look:
PHP Code:
/**
 * this function checks if a user is currently logged in.
 *  if so, it sets up the user's info for hedgeclipper to use.
 * 
 * @return bool                 true if the user is logged in; false otherwise
 */
function hedgeclipper_checkLoggedIn(){
    # hedgeclipper info is stored in session, so make sure one has been started.
    if( !session_id() ){ session_start(); }

    # check if there are any hooks to do
    hedgeclipper_doHook( 'checkLoggedIn_start' );

    # check if hedgeclipper info exists:
    if( !empty( $_SESSION['hedgeclipper'] ) ){
        # pull the data from the session;
        # hedgeclipper_userinfo() validates and stores it
        if( hedgeclipper_userinfo( $_SESSION['hedgeclipper'] ) ){
            # now we can check if the user has logged in or not:
            if( # start with a basic login check
                hedgeclipper_userinfo( 'auth','last_login' ) > 0 
                # and see if there's a hook also
                && hedgeclipper_doHook( 'checkLoggedIn_success' )
            ){
                # all good.
                return true;
            }
        }
    }
    # if we get to this point, either the user is not logged in, or something went wrong.
    hedgeclipper_doHook( 'checkLoggedIn_fail' );
    return false;
} 
Hedgeclipper stores user info in the $_SESSION superglobal, so basically, this function just checks if there is any user login info present. last_login contains a unix timestamp, set when the user last logged in - if it's 0, the user hasn't logged in yet. If it's greater than 0, then we have a record of the user logging in, and we don't need to ask again.

There are several spots in this function where we call another function called hedgeclipper_doHook(). This is fun: if there is a function in the hedgeclipper options tied to a particular event, this will run that function and return the result. This allows us to add custom functionality without rewriting (and possibly breaking!) the actual hedgeclipper functions.

For example, we might want hedgeclipper to check not only if the user logged in, but that they logged in recently. No problem!
PHP Code:
# EXAMPLE USAGE - not part of hedgeclipper #
// write a custom check function:
function check_recentLogin(){
    # check if login was within last hour
    if( hedgeclipper_userinfo( 'auth','last_login' ) > time() + 60*60 ){
        return true;
    }
    # not recent...  :(
    return false;
}

// register our "hook" in options, under the "checkLoggedIn_success" event:
hedgeclipper_options( array( 'hooks'=>array( 'checkLoggedIn_success'=>'check_recentLogin' ) ) ); 
Now, if the user logged in more than an hour ago, this function will return FALSE and the login check will fail.

Another function that both these functions call is hedgeclipper_userinfo(). This one work similarly to the hedgeclipper_options() function, except that it doesn't manage options: it manages information about the user.

There are three categories of information to manage:
  • auth. Info about authentication (login status) and authorization (permissions).
  • user. Info about the user specifically (e.g., their name, email, etc.).
  • app. Arbitrary info that's not specifically about the user or their authorization, but you want to associate with the user and their session. User preferences might be a good example of info to store here.
PHP Code:
/**
 * this function organizes and stores all the info hedgeclipper needs.
 *
 * @param string $mode          determines category to use: "auth","user","app"
 *                              also accepts "all" to get the whole $userinfo array.
 * @param string|array $info    to *get* info, pass the key name
 *                              to *set* info, pass an array with "key"=>"new info"
 * @return string|bool          the info if requested, or TRUE if new info was set;
 *                              FALSE otherwise
 */
function hedgeclipper_userinfo( $mode,$info=null ){
    # static containers for each userinfo category
    static $auth;
    static $user;
    static $app;

    # set defaults for each userinfo category
    if( empty( $auth ) ){ $auth = hedgeclipper_userinfo_auth_default(); }
    if( empty( $user ) ){ $user = hedgeclipper_userinfo_user_default(); }
    if( empty( $app  ) ){ $app  = hedgeclipper_userinfo_app_default();  }

    # check $mode:
    switch( $mode ){
        # use $auth array:
        case 'auth':
            # if $info is the name of an $auth key, return that item's value.
            if( is_string( $info ) && array_key_exists( $auth[$info] ) ){
                return $auth[$info];
            }
            # if $auth contains the name of an $auth key and a value, set the key to that value.
            if( is_array( $info ) && (count( $info ) == 2) && array_key_exists( $auth[$info[0]] ) ){
                $auth[$info[0]] = $info[1];
                return true;
            }
            # otherwise, return false.
            return false;
        # use $user array:
        case 'user':
            # works the same way as "auth".
            if( is_string( $info ) && array_key_exists( $user[$info] ) ){
                return $user[$info];
            }
            if( is_array( $info ) && (count( $info ) == 2) && array_key_exists( $user[$info[0]] ) ){
                $user[$info[0]] = $info[1];
                return true;
            }
            return false;
        # use $app:
        case 'app':
            # works the same way, but allows new keys to be set arbitrarily.
            if( is_string( $info ) && array_key_exists( $app[$info] ){
                return $app[$info];
            }
            if( is_array( $info ) && (count( $info ) == 2) ){
                $app[$info[0]] = $info[1];
                return true;
            }
            return false;
        # use all:
        case 'all':
            # set all new userinfo
            if( is_array( $info ) && isset( $info['auth'] ) && isset( $info['user'] ) && isset( $info['app'] ) ){
                $auth = $info['auth'];
                $user = $info['user'];
                $app  = $info['app'];
                return true;
            }
            return array( $auth,$user,$app );
        # do nothing:
        default: return;
    }
} 
There are a few functions that this function uses to set up default values for "auth", "user", and "app". This is also where you can "hook" your own functions, if you want to add to the default items. Because this post is too long already, I'll link to those functions so you can check 'em out.

The last bit of code we'll look at today is hedgeclipper_checkLoggedIn()'s complementary function: where checkLoggedIn gets info from the session, hedgeclipper_rememberLoggedIn() will store info in the session.
PHP Code:
/**
 * this function updates the php session with hedgeclipper's info.
 */
function hedgeclipper_rememberLoggedIn(){
    # update the "last activity" time
    hedgeclipper_userinfo( 'auth',array( 'last_activity','now' ) );

    # save all hedgeclipper userinfo to session
    if( !session_id() ){ session_start(); }
    $_SESSION['hedgeclipper'] = hedgeclipper_userinfo( 'all' );
} 
Let's take a quick break from coding and look at some good ol'fashioned HTML. We're going to put our HTML in "template" files - that way, we can keep it organized and we can also edit or replace individual parts easily.
hedgeclippertemplate.loginform.html
HTML Code:
<!--------------------------------------------
html markup for hedgeclipper login form.
    there are two "placeholders" in the markup.
    the hedgeclipper functions will look for and replace them with dynamic values:
    -- %action% will be replaced by the appropriate URL to submit the form to.
    -- %token% will be replaced by a unique security token to help prevent brute force attacks.
-------------------------------------------->
<form class="hedgeclipper_login" action="%action%" method="post">
    <fieldset>
        <legend>log in with <b>hedgeclipper</b></legend>
        <input type="hidden" name="hedgeclipper[token]" value="%token%">
        <p><label for="hedgeclipper[email]">Email: </label><input type="email" name="hedgeclipper[email]" required>
        <p><label for="hedgeclipper[password]">Password: </label><input type="password" name="hedgeclipper[password]" required>
        <p><label>&nbsp;</label><input type="submit" value="Log In">
    </fieldset>
</form>
In your browser, the form will look something like this:

You might clean it up with some basic CSS:
Code:
.hedgeclipper_login{ border: 1px outset gray; background: #eee; font-family: sans-serif; }
.hedgeclipper_login label{ display: inline-block; width: 8em; }


That's a lot of stuff we covered...! Next time, we'll look how to handle actual login attempts, and also some database stuff!

See ya next time,

-Adrian ]]> traq http://www.dynamicdrive.com/forums/entry.php?275-HedgeClipper-part-2-! <![CDATA[A Really Big PHP Tutorial [...part 1]]]> http://www.dynamicdrive.com/forums/entry.php?273-A-Really-Big-PHP-Tutorial-part-1 Mon, 17 Dec 2012 03:04:07 GMT .
Who Is This For?

I'm going to make some assumptions about you, as a programmer:
  • You're probably not an expert with PHP, but you know at least "the basics."
    If you're a copy+paste PHP coder, that's okay, but hopefully you won't be once we're done.
  • You have some patience. Yes, you want to see results; but you can trust that they're coming.
  • You're "okay" with doing things you've never tried before.

There are some things I would like you to know before we get started.

While I assume that you know your way around a basic PHP script, I want to assure you that if you're a newbie, nothing in here will break you! This tutorial is more about "the plan," and how to write scripts, and less about understanding all those complicated, obscure, hyper-abstracted details that I usually blather on about.

It is a long endeavor - my guess is four to six posts. That "patience" thing I mentioned above will pay off. There are going to be lots of little things that we set up in one part of the tutorial, but don't get around to using until much later.


What Are We Doing?

We're going to build something. We're going to create a user log-in system.

I shall call it hedgeclipper.

I've mentioned before that, when you write a program, it's a good idea to write it PHP-first. So we're going to do that. A neat side-effect of PHP-first is that it forces you to plan out your application - since you're not just writing code "as you think of it," you need to know what you're going to write in advance.

So let's make some goals for hedgeclipper. First, the obvious:
  • Requires the person trying to access the page/program to be logged in.
  • Allows the person to log in/out.
  • Is secure*
    *     What "secure" implies is deserving of its own discussion, but let's not interrupt our "flow" right now.

Some not-so-obvious goals:
  • Flexible: Can be configured and used in different ways on a page-specific basis.
  • Extensible: Code can be changed easily; adding, removing, or switching features is not difficult.
  • Portable: Can be used on new or existing pages, on different sites or servers, or with different codebases.

And a "Feature List":
  • verify username + password
  • track logged-in status (so we don't have to login on every request)
  • control access to restricted pages
  • control access to restricted content on pages
  • allow user to log out


Sounds simple, right? :p

Notice that, to start, we're not going to worry about some common features, like registration pages, email validation, password recovery, or permissions and groups. That doesn't mean we won't: we're just going to start with the bare minimum. But we're going to make the code flexible enough that we can add these features (and more!) later on, without making a huge mess in the process.

We are going to make control panels (how else could we set up user accounts/passwords?). Those will come later, on a separate page.

Next, describe the situations hedgeclipper might encounter, and what it should do in those situations.

...What if we need to configure options for the program (hint: we do)?
Do it!
...What if we need to find out if the user is logged in or not (hint: we do)?
...What if the user already logged in?
Cool. I'll remember that.
...What if the user is logging in right now?
...What if the login attempt is valid?
Cool. I'll remember that.
...What if it's no good?
Reject the login attempt.
...What if the user is logging out?
Cool. I'll remember that.
...What if the user is not logged in, and only logged-in users are allowed to continue?
Require user to log in.


Guess What?

We just wrote hedgeclipper's main controller script.

hedgeclipper_controller()
PHP Code:
/**
 * this function allows _hedgeclipper_ to decide what it should do.
 *
 * @param array|null $options           configuration options. we'll talk a little about this next.
 */
function hedgeclipper_controller( $options=null ){

    # What if we need to configure options for the program (hint: we do)?
    # Do it!
    hedgeclipperOptions( $options );
    
    # What if we need to find out if the user is logged in or not (hint: we do)?
    # What if the user already logged in?
    if( hedgeclipper_checkLoggedIn() ){
    
        # Cool.  I'll remember that.
        hedgeclipper_rememberLoggedIn();
        
    # What if the user is logging in *right now*?
    }elseif( hedgeclipper_isLoggingIn() ){
    
        # What if the login attempt is valid?
        if( hedgeclipper_validateLogin() ){
        
            # Cool.  I'll remember that.
            hedgeclipper_rememberLoggedIn();
            
        # What if it's no good?
        }else{
        
            # Reject the login attempt.
            hedgeclipper_forgetLoggedIn();
            hedgeclipper_loginFailed();
        }
    }
    
    # What if the user is logging out?
    if( hedgeclipper_isLoggingOut() ){
        
        # Cool.  I'll remember that.
        hedgeclipper_forgetLoggedIn();
    }
    
    # What if the user is not logged in, and only logged-in users are allowed to continue?
    if( hedgeclipperOptions( 'restrict' ) ){
    
        # Require user to log in.
        hedgeclipper_requireLogin();
    }
} 
Hard part's over. : )

Now, we just need to write out what all those functions do. The first thing we'll look at is how we handle setting and checking configuration options.

hedgeclipperOptions()
PHP Code:
/**
 * this function keeps track of hedgeclipper's configuration settings.
 *  it also handles setting custom options, and returns option values when requested.
 *
 * @param string|array $opt     if $opt is a string, we're asking for the value of the matching config setting.
 *                              if $opt is an array, we're setting config options with specific values.
 * @return mixed                returns the value of $opt if $opt is a config option; FALSE otherwise.
 */
function hedgeclipperOptions( $opt=null ){
    
    # more about `static` in the paragraph below
    static $options;
    
    # assign default values to configuration options if none exist
    if( empty( $options ) ){
        $options = array(
            'datatype'      => 'mysqli'
           ,'datasource'    => null
           ,'deny'          => ''
           ,'expiry'        => null
           ,'hooks'         => array()
           ,'restrict'      => true
        );
    }
    
    # if $opt is an array, use it to update $options
    if( is_array( $opt ) ){
        $options = array_merge( $options,$opt ); 
        return;
    }
    
    # if $opt is a string, and a matching setting exists in $options, return its value
    if( is_string( $opt ) && isset( $options[$opt] ) ){
        return $options[$opt];
    }
    
    # if we get to this point, nothing went right.
    return false;
    
} 
If you know about how PHP handles scope, you might be confused by the variable $options in this function. Normally, variables inside of functions are limited to that function: they "disappear" when the function completes, and are "restarted" every time the function is called. That would make defining our $options inside the function basically useless: they'd be *gone* when the function ended.

The static operator changes that - the variable is still accessible only from the function's scope, but its contents are preserved when the function completes. That's what allows us to use this function to "look up" values - the function remembers what is in $options between calls. Interestingly, this allows us to change options in the middle of our program, or even make up new config settings - but we can explore that later.

You might also wonder about our datasource. For this tutorial, we're going to use a MySQL database as our data source - many, many websites already use MySQL for something, so we'll take advantage of that by passing the database handle into our functions, rather than creating a new connection.

We mentioned restrict earlier, and we'll mention deny and hooks later. :)


Next Time

In part two, we'll talk about how to check if a user is logged in or not, and we'll write the following functions:
  • hedgeclipper_checkLoggedIn()
  • hedgeclipper_rememberLoggedIn()

We'll also write some HTML, so we have an idea of what our users are looking at on the front-end.

I'll give you a week or so to stew, but in the meantime, Please Ask Questions!

'Till then,

-Adrian ]]> traq http://www.dynamicdrive.com/forums/entry.php?273-A-Really-Big-PHP-Tutorial-part-1 <![CDATA[Heaps o' Fun]]> http://www.dynamicdrive.com/forums/entry.php?272-Heaps-o-Fun Thu, 13 Dec 2012 07:08:12 GMT yes, I'm still doing the tutorial. : )

Did you know ...?

PHP Code:
<?php

class alphaHeap extends SplHeap{
    public function compare( $a,$b ){
        return strcmp( $b,$a );
    }
}

$alpha = new alphaHeap;

# IN put:
$alpha->insert( 'cat' );       // C
$alpha->insert( 'dog' );       // D
$alpha->insert( 'boy' );       // B
$alpha->insert( 'elephant' );  // E
$alpha->insert( 'apple' );     // A

foreach( $alpha as $str ){ print "$str<br>"; }
#OUT put:
/*
apple     // A
boy       // B
cat       // C
dog       // D
elephant  // E
*/

a Heap

...is a data structure commonly used for sorting values. They're very efficient (edit: 35%-40% faster, in fact). I don't have an expert understanding, but here's a good place to read more.

In practice, you might think of a Heap as an Ordered List.

With normal PHP arrays, new values are inserted either according to their numeric keys, at a specific position using a complicated sequence of array_slice(), array_push() or array_unshift(), and/or array_splice(), or are (often) simply appended to the end of the array. You have to be responsible for sorting these yourself, sometimes several times during script execution, which can lead to complicated loops or multi-dimensional indexing. With a Heap, new values are "sifted" (compared and ordered) when they're inserted, so the Heap is always in the correct order.


the Standard PHP Library

...is a collection of object classes that most PHP coders have never even heard of. Shame, really. There's some great stuff in there - like Heaps.

The SplHeap class is ready to go, with everything you need, save one lil' detail: how to order the data. You have to define that yourself.*

*The SPL also provides the truly ready-to-use SplMinHeap and SplMaxHeap classes, which order things (you guessed it!) smallest-first and largest-first, respectively. But you can do such cool stuff with your own implementation!

In my first example, I used the SplHeap's ::compare() method to sort words alphabetically. But you can do any number of other things. Just extend the SplHeap class, and write your own version of compare() (compare() must return -1 [less-than], 0 [equal], or 1 [greater-than]). Try these:
PHP Code:
<?php
# biggest word first
class bigWordHeap extends SplHeap{
    public function compare( $a,$b ){
        return strlen( $a ) > strlen( $b )? 1: -1; 
    }
}
# fewest vowels first
class fewestVowelsHeap extends SplHeap{
    public function compare( $a,$b ){ 
        $A = $this->numVowels( $a );
        $B = $this->numVowels( $b );
        if( $A === $B ){ return 0; }
        return $A > $B ? 1: -1;
    }
    private function numVowels( $str ){
        $vowels = array( 'a','e','i','o','u' );
        $letters = str_split( $str );
        $totalVowels = 0;
        foreach( $letters as $ltr ){
            if( in_array( $ltr,$vowels ) ){ $totalVowels++; }
        }
        return $totalVowels;
    }
}
# who knows first
class randomOrderHeap extends SplHeap{
    public function compare( $a,$b ){ 
        return rand( -1,1 );
    }
}

It Gets Better

All well and good, right? "But we already have the various sort() functions for arrays, and I already know how to use those." Check this out.

Say you're getting info about a bunch of people from your database.
Code:
SELECT `name`,`age` FROM `people`
You get your result set (and NOT by using the mysql_*() functions, of course) and put it in an array. For simplicity, we'll say you end up with something like this:
PHP Code:
$example_resultSet = array(
    array( 'name'=>'John'    ,'age'=>22 )
   ,array( 'name'=>'Mary'    ,'age'=>44 )
   ,array( 'name'=>'Albert'  ,'age'=>48 )
   ,array( 'name'=>'Vincent' ,'age'=>22 )
   ,array( 'name'=>'Jane'    ,'age'=>19 )
   ,array( 'name'=>'Michael' ,'age'=>22 )
   ,array( 'name'=>'Julia'   ,'age'=>22 )
   ,array( 'name'=>'Heather' ,'age'=>32 )
   ,array( 'name'=>'George'  ,'age'=>25 )
   ,array( 'name'=>'Erin'    ,'age'=>48 )
); 
Each item in this example "result set" represents a "row" from our query. Say you want to order everyone from oldest to youngest - but we seem to have a lot of people who are the same age. Not being anarchists

(UNSORTED DATA!!?! HERETIC!!!),

we decide that people who are the same age should be grouped and sorted alphabetically.
PHP Code:
<?php

class ageGroupAlphaHeap extends SplHeap{
    public function compare( $a,$b ){
        if( $a['age'] === $b['age'] ){
            return strcmp( $b['name'],$a['name'] );
        }
        return $a['age'] > $b['age']? 1: -1;
    }
}

# instantiate Heap
$sorted_resultSet = new ageGroupAlphaHeap;

# insert each row from our *unsorted* result set
foreach( $example_resultSet as $row ){ $sorted_resultSet->insert( $row ); }

# print out our *sorted* records
foreach( $sorted_resultSet as $person ){ print "{$person['age']} year-old {$person['name']}.<br>"; }

# Output:
/*
48 year-old Albert.
48 year-old Erin.
44 year-old Mary.
32 year-old Heather.
25 year-old George.
22 year-old John.
22 year-old Julia.
22 year-old Michael.
22 year-old Vincent.
19 year-old Jane.
*/
What's more, if we add another "row" later on, everything is still in proper order -
PHP Code:
<?php
$newRow = array( 'name'=>'Bethany','age'=>27 );

$sorted_resultSet->insert( $newRow );

foreach( $sorted_resultSet as $person ){ print "{$person['age']} year-old {$person['name']}.<br>"; }

# Output:
/*
48 year-old Albert.
48 year-old Erin.
44 year-old Mary.
32 year-old Heather.
27 year-old Bethany.
25 year-old George.
22 year-old John.
22 year-old Julia.
22 year-old Michael.
22 year-old Vincent.
19 year-old Jane.
*/
...and we got to be lazy about it. :)


Enjoy

SPL also has other interesting and useful data structures, iteritors, functions, and classes. Check them out. You might find something awesome for your next project.

Please Ask Questions,

-Adrian ]]> traq http://www.dynamicdrive.com/forums/entry.php?272-Heaps-o-Fun Not My Type... : ) http://www.dynamicdrive.com/forums/entry.php?270-Not-My-Type-) Thu, 29 Nov 2012 05:13:42 GMT Yes, the tutorial is still coming. It's big. It's in progress. :)

I read this recently and was intrigued. Don't know if anyone else would care or not ...:)

The author, nikic, does a great job summarizing the difficulties and potential benefits of type hinting, as well as giving a good explanation as to why PHP's implementation is incomplete. Personally, I look forward to being able to type-hint any type. It could save me a lot of code validating args, and I could focus more on actually writing code.

Lost?

If you're not familiar with what is being talked about...

PHP (javascript too, coincidentially, but of course it's implemented differently) is loosely typed.
PHP Code:
<?php

# this is a string (a _text character_, no different than 'a', 'b', or 'c').
$string = '5';
# this is an integer (a _whole number_, like 1, 2, or 3).
$int = 5;

print $string + $int;
In a "strictly typed" language (like C++ or Java, for example), this would result in an error:
.....Error ID:10T [you can't do math with sentences]

or something like that. But PHP does somthing called "type juggling": when it needs a number, it does its darndest to _have_ a number. Since "5" is reasonably equivalent to 5, it casts the string "5" to an integer (5). The string becomes an integer: literally, silently, automatically; and the output is as expected:
.....10

PHP is loosely typed for a very, very important reason: it's a web language. Data comes and goes across the internet. Data comes and goes across the internet as strings.

That's right, there's no such thing as an "integer" over HTTP. When you type in a URL, it's sent as text. When you submit a form, it's sent as text. Even if it's all numbers. Every $_GET or $_POST variable that PHP populates starts out as a string. But, you might need to do math with them, and thanks to type juggling you can.

(Incidentially, type juggling is also the reason you can do if( $variable ). if() needs a boolean (TRUE/FALSE) value, so PHP type-juggles and casts $variable to a boolean.

(The rules about this process are kinda interesting, and the results sometimes more so. For example:
PHP Code:
<?php

$int = 10000;               // integer (10,000)
$str = "10,000";            // string "10,000"
$sum = $int + $str;         // integer (10,010)

$int = 5;                   // integer (5)
$str = "5";                 // string "5"
$int .= $str;               // string "55"

$a = array( 'a','b','c' );  // array (3)
$a .= 'd';                  // string "Arrayd"

$str = "No";                // string "No"
$bool = true;               // boolean (TRUE)
$sum = $str + $bool;        // integer (1)
$sen = $str.$bool;          // string "No1"

if( "FALSE" ){ /* true. */ }
(...some of these might seem ...logical... once you think about it for a while. But did you really expect to add a string to a boolean and get an integer? Anyway... this is a different discussion.)

Need a Hint?

Along with type juggling and type casting, PHP 5.1 introduced type hinting, and 5.4 has added more to it. Basically, you can make your functions require a particular type of argument. Here's a function that needs an array:
PHP Code:
<?php
function loop_d_loo( $array ){
    print "looping through array:\n";
    foreach( $array as $item ){ 
        /* do something loopy */ 
    }
}
but what if you forget?
PHP Code:
<?php
loop_d_loo( 42 );
# > looping through array:
# > Warning: Invalid argument supplied for foreach() ...
But wait ...! You can use type hinting:
PHP Code:
<?php
function loop_d_loo( array $array ){
    print "looping through array:\n";
    foreach( $array as $item ){ 
        /* do something loopy */ 
    }
}

loop_d_loo( 42 );
# > Catchable fatal error: Argument 1 passed to loop_d_loo() must be of the type array, integer given ...
You might say "an error is an error," and you'd be right, but the error in the second case is preferable for two reasons:
  1. The function is not executed at all, leaving no "broken" data or half-baked output.
  2. The error message is more descriptive and more accurately describes where the problem really came from, leading to better bug-fixin'.
    Actually, with exception based error handling and set_error_handler(), you can deal with the problem at runtime (by skipping it, or even casting the bad argument to the proper type or substituting a default value).


PHP 5.1+ allows you to hint that your argument needs to be an object (even of a particular class, or using a particular interface) or an array. Version 5.4 allows you to require an argument to be callable (a function/method or name of a function/method).

Back To Basics

You'll notice that the basic types, like integer, string, boolean, and so forth, are missing: you cannot use type hinting for scalar types (a "scalar" type is one that can only hold one value at a time, as opposed to arrays or objects, which can hold multiple values). You might think that scalar type hinting would be easier than with other types - that's the misconception that the article I referred to earlier was discussing.

The non-scalar types are easier to "hint at" because they aren't easily type-juggled - and under normal circumstances, no one would want them to be. (Why would you want to treat an object that contains a dozen properties (values) as a single value? How would it even make sense to try?) I have to admit that there are complications I never even thought of, but the author's favorite solution is the one I had in mind before I started reading: Strict Weak Hinting (with casts).

I think it would be quite useful if you could specify that you wanted a integer, and, given an argument looked like an integer, you would get one.

This would involve type juggling and casting working together: if the argument can be cast to the hinted type, and there is no loss of data, then cast it to the hinted type. Otherwise, throw an error. For example:
PHP Code:
<?php
# NOT REAL PHP #

function intHint( int $int ){ /* do us some maths */ }

intHint( 1 );       // integer (1): we're all good.
intHint( "1" );     // string "1" - but equivalent to (1), so cast it and we're all good.
intHint( 1.5 );     // float (1.5) - casting to int would give (1), which is *not* equivalent to 1.5: throw an error.
intHint( "one" );   // string "one" - would be cast to (0), which is not equivalent: throw an error.
intHint( true );    // bool (TRUE) - casting to int would give (1), which is equivalent - but...  
                    //    I'm not sure about this one.
In Conclusion

That's my random thoughts for the day. Anyone care to share theirs?

Happy coding,

- Adrian ]]> traq http://www.dynamicdrive.com/forums/entry.php?270-Not-My-Type-) Before You Start: the basics, for PHP in particular and for programming in general http://www.dynamicdrive.com/forums/entry.php?269-Before-You-Start-the-basics-for-PHP-in-particular-and-for-programming-in-general Fri, 23 Nov 2012 07:18:59 GMT I wanted to take a few moments to talk about some of "the basics" that are all-to-often glossed over...

A Matter of Style

In general, I find that most PHP programmers fall into one of three main programming styles:
  • procedural: a simple ordered set of instructions, nested if's/ else's, etc.
  • functional: functions are little code containers that you can call on when needed. You [usually] give them arguments, they [usually] return values to you.
  • object-oriented: objects wrap up a set of functions and related information (properties) to represent a complete "thing" in your program. You have whatever objects you need, and you manipulate them using their methods (functions).


I'm a big fan of Object-Oriented Programming. Objects are very flexible and allow you to do things you'd never have thought possible otherwise. Even for tasks that could be accomplished without Objects, OOP is really cool and builds lots of good programming habits.

There's style, and then there's Style.

When it comes to writing your program, how you do it is important.

  • Use a good plain text editor with (at a minimum) syntax highlighting. Some recommendations:

    Microsoft Word is not a good choice for programming. Less obviously, programs like DreamWeaver and FrontPage often produce buggy, poor-performing sites. Quite simply, they're made for people who don't know what they're doing: you sacrifice control and quality for convenience.
    .
  • Format your code. You're not "wasting space" by indenting your code. You're not "slowing down the program" by adding comments. You're not being an "eLiTe haX0r" by writing code so "clever" that no one has any hope of deciphering it later.

Compare:
Code:
    function find( $find,$val=null )
{
$recurse = function( $obj )use( &$prop,$val,&$recurse )
{
              $p = array_shift( $prop ); return isset( $obj->$p )? empty( $prop )? is_null( $val )? true: ($obj->$p === $val): $recurse( $obj->$p ): false;
};
   foreach( $this as $obj )
{ $prop = strpos( $find,'.' )? explode( '.',$find ): (array)$find;
if( $recurse( $obj ) )
{ return $obj; 
}
}return false;          
}
PHP Code:
/**
 * searches storage for an object containing property $find; optionally with value === $val
 * @param string $find              name of property to find (in the form `object.property`)
 * @param mixed $val                value to match property against
 * @returns bool|object             object if match found; false otherwise
 */
function find( $find,$val=null ){
    
    /** closure bool            recurses through an object->property chain to search for property. */
    $recurse = function( $obj )use( &$prop,$val,&$recurse ){
        $p = array_shift( $prop );
        return isset( $obj->$p )?
            empty( $prop )?
                is_null( $val )?
                    true:
                    ($obj->$p === $val):
                $recurse( $obj->$p ):
            false
        ;
    };
    
    # search stored objects for matching property [& value]; return if found
    foreach( $this as $obj ){
        // parse property chain
        $prop = strpos( $find,'.' )? explode( '.',$find ): (array)$find;
        // recurse
        if( $recurse( $obj ) ){ return $obj; }
    }
    
    # no matches found
    return false;
} 
Take it to heart.

Server Set-Up

I'm running PHP version 5.4. You should too. It's fantastic.

However, there's nothing wrong with version 5.3. It came out in 2009, so there's no excuse to not have some release of it. If you're still on 5.2, you really need to upgrade. If your web host doesn't offer 5.3+, you should be looking for a new host.

Edit: I know many people are stuck with older codebases.
5.2 is "okay," if you're not in a position to leave it behind. But your goal should be to upgrade.


If you don't have 5.4, check these settings in your php.ini file. Make sure:
  • safe mode is turned OFF
  • register_globals is turned OFF
  • register_long_arrays is turned OFF
  • magic_quotes_gpc is turned OFF

These things aren't safe at all (no, not even safe mode). They cause problems. Don't use them.
(Talk to your web host.)

Fun and Games and Error Messages

We should have a brief word about development vs. production:
  1. development is when you are writing and testing your code.
    .
    When you're in development, you want to see every last error message. You want your program to crash and burn at every little bump in the road. You want PHP to complain endlessly about absolutely everything.
    .
    Why? ...why indeed.
    .
  2. production is when you put your code up on your website for all to see.
    .
    When you're in production, it's completely different. If there's a problem, you want to hide it at all costs.
    .
    Error messages? NO!
    If it's so bad a problem that you can't recover, blame the dinosaurs - not your program. No one "hacks" dinosaurs. But if you mention that something went wrong because {function} couldn't connect to {host} on {socket} with {username} and {variable} had an unexpected {value}, you can bet someone, somewhere, will start hacking away .


In the spirit of Development, use these settings in your php.ini file:
Code:
error_reporting = E_ALL & E_STRICT
display_errors = On
display_startup_errors = On
You can also do this at the top of your script:
PHP Code:
<?php
error_reporting( -1 );
ini_set( 'display_errors','On' );
However, it's not as useful, and it won't always work. : (

Remember, in Production, both display_errors and display_startup_errors should be Off.

I Did Everything Right and My Code Still Broke

This is not unusual.
(Everyone thinks they did everything right.)
No, I believe you.
Really.

Situation #1

Something is wrong with your code. You're getting all kinds of crazy error messages. They say obscure things like
Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM, expecting ')' in ...
or
Warning: [function.session-start]: Cannot send session cache limiter - headers already sent ...
Don't Panic.

Error messages are your friends.

Quite often, they are simply the result of typos. Just read the message - it tells you exactly what's wrong. If you don't understand something in the message, google it. You're all big boys and girls; you're allowed to use the internet on your own.

If the problem is not obvious, and the 'net fails you, then sit back and take a good look at your code. Start at the line number the error message gave you, and work backwards. (There's a fundamental truth to be uncovered here: PHP doesn't actually know where the problem was caused; it knows only where the problem got unfixable.)

For example:
Parse error: syntax error, unexpected 'print' (T_PRINT) ...on line 2
Code:
2 >   print "hello";
That looks fine, right? Hint: back up.
Code:
1 >   some_function( 'this does cool stuff' )  // <---WHUP NO CLOSING SEMICOLON
problem solved.

Situation #2:

Something is wrong with your code. You're not getting any error messages at all. But your webpage says "Vote For The Cutest Kitten" AND THERES ABSOLUTELY NO CATS ANYWHERE. Maybe there is no error - maybe what you wrote just doesn't do what you expected.

Don't Panic.

This is where version control come into play. "Undo" is just not good enough when it comes to managing your code. Ya know how people tell ya, "backup your files"? If you don't want to get into using version control systems,* like subversion or git, you need to at least make it a habit to "backup your files" every time you make a significant change. I don't mean having several copies of the latest version - you should be able to "revert" to any of the last two or three working versions of your scripts.

*Yes, I said "if you want to." There are people who will be mad at me because I didn't say you have to. However, I will say that, if you're doing anything more than "messing around," you really, really should be using a VCS. It's well worth it.

Where Do We Go From Here?

We're going to build a Web App. All kinds of bells and whistles and shiney stuff. Coming soon to a blog near you. Look for it.

PAQ,
- Adrian ]]> traq http://www.dynamicdrive.com/forums/entry.php?269-Before-You-Start-the-basics-for-PHP-in-particular-and-for-programming-in-general Taking Control http://www.dynamicdrive.com/forums/entry.php?268-Taking-Control Fri, 09 Nov 2012 02:22:52 GMT Last week, I wrote about taking a "PHP-first" approach to programming - program first, output last. But what should go first in your program?

M-V-C
You may have heard about something called "MVC" (Model-View-Controller). If not, here's your crash course:

Model

Your Model is all of the information needed/used by your program. [Hopefully], the Model is well-organized. Think of it in terms of note-taking: notes are easier to read when they're organized by subject, sub-subject, etc. than when they're just scribbled haphazardly all over the margins of your textbook.

(Yes, I know that some people - and yes, I'm one of them - actually function better with a huge glob of cryptic post-its ...or we seem to prefer things that way, at least... but we do not think like computers. Computers don't like post-its. Trust me.)

View

Your View is how all that information is supposed to be displayed. In our domain - Web Design - it's actually very easy to figure out what belongs in the View: output! If there's HTML, then it belongs in the View. Likewise, CSS, JavaScript, even HTTP Headers, etc., belong here.

Learning "PHP-first" helps by separating all of the output from the rest of the program. However, consider that the View is not the output itself, but all of the stuff that is going to be output. An example, where we show a comment on a page:

PHP Code:
<?php

// Model: the information we need
list( $message,$author,$publish_date ) = get_comment( $commentID );

// (`$commentID` is some identifier for the comment we want (e.g., a DB record id))


// View: not output *yet*, but it *will be*!
$comment = <<< HTML
    <article class="comment">
        <p>$message</p>
        <p class="author">Published by $author on $publish_date.</p>
    </article>
HTML
;

// View?  no...   than what?
print $comment;
Controller

The Controller is the missing part of the plan. The Controller controls everything. It's the parts of your script that check conditions, make decisions, and order things to be done. In the above example, the last line is part of the controller: it tells the script what to do (i.e., print something). There is probably some other Controller code [not shown in the example] that decided to build the comment in the first place - some sort of if( this ){ then; }else{ that; }.

So, any given PHP script probably has two types of Controller code:
  • code that makes decisions, and
  • instructions for carrying out decisions.


With a Controller, our example might look something like this:

PHP Code:
<?php

// controller logic (decide what to do):
//   IF the user asked for a comment,
if( !empty( $_GET['comment_id'] ) ){
    // procedure (instructions on what to do):
    //   get the comment they want.
    $model = getComment( $_GET['id'] );
    $view = prepareComment( $model );

// controller logic:
//   OTHERWISE,
}else{
    // procedure: 
    //   show a random comment.
    $model = getComment( NULL );
    $view = prepareComment( $model );
}

// procedure:
print $view;
You'll notice that there's not a lot of code inside each if{} and else{} block - just a few calls to functions. This is done on purpose. While a coder's first thought might be to put all of the instructions right inside the block where they're being used, you'll end up with lots of nested blocks that way - it quickly becomes difficult to keep track of your Controller's logic, and mistakes start showing up. Just like we're separating the PHP from its output, we'll separate the Model and View from their Controller. This has the side-effect of making the code reusable (instead of writing all the code twice, just call the function again).

This pattern repeats throughout the program. The functions used in the Controller (to create the Model and the View) contain their own Controllers:

PHP Code:
<?php

function getComment( $commentID=NULL ){
    // controller: two possibilities...
    // 1) we want a random comment (specified by making $commentID=NULL).
    if( is_null( $commentID ) ){
        /* get a random comment */
        // we might have gotten this info from a database, or somewhere else -
        //   doesn't really matter for this example.
        //   What's important is, if we get the info, we return it in an array:
        return array( $message,$author,$publish_date );
        
    // 2) we want a specific comment (specified by a non-NULL $commentID).
    }else{
        /* get the comment with commentID = $commentID */
        // again, if you find the info, return it.
        return array( $message,$author,$publish_date );
    }
    
    // HA! you say.  A third possibility!
    //   what if we wanted $commentID, but we couldn't find it?
    // well, if we found it, then this function has already returned (finished).
    // if not, then this last bit of code will be executed:
    return FALSE;
    //   ...and will indicate that we didn't get what we wanted.
}

function prepareComment( $model=FALSE ){
    // controller: two possibilities...
    // 1) $model is an array, returned from getComment().
    if( is_array( $model ) ){
        // get the info from the Model
        list( $message,$author,$publish_date ) = $model;
        
        // use it to create the view
        $comment = <<< HTML
    <article class="comment">
        <p>$message</p>
        <p class="author">Published by $author on $publish_date.</p>
    </article>
HTML
;
        // and return the view (for the controller to print later).
        return $view;
    }
    // 2) $model is not an array (should be FALSE, indicating the comment wasn't found)
    // return an error message.
    return <<< HTML
    <p class="error">I'm sorry, the monkeys couldn't find that comment.</p>
HTML
;
}

Hint, Hint, Hint...

You might see some possible complications in the code above: there may be some cases where errors would creep in and break things. But error handling is a topic for another day... :)

PAQ (Please Ask Questions),
- Adrian ]]> traq http://www.dynamicdrive.com/forums/entry.php?268-Taking-Control Every PHP Tutorial Is Wrong http://www.dynamicdrive.com/forums/entry.php?267-Every-PHP-Tutorial-Is-Wrong Fri, 02 Nov 2012 23:24:41 GMT tags, and usually the echo construct. For example, something like this: PHP: --------- My First PHP Page ]]> Many PHP tutorials begin with an introduction to the "basics" of the language: the <?php ?> tags, and usually the echo construct. For example, something like this:

PHP Code:
<html>
<head>
    <title>My First PHP Page</title>
</head>
<body>
    <?php
        echo "Hello World!";
    ?>
</body>
</html>
Before I blast this, I want to make clear that it's definitely not one of the worst examples out there. It actually parses! Additionally, the reason this is "Wrong" has nothing to do with the example itself, but with how it is presented.

Hello, World!

PHP is very welcoming to new coders because of the flexibility it allows in writing code, and, more importantly, in integrating that code with your HTML. Just open PHP (<?php), write your code, and close PHP (?>) to get back to your HTML page. A nice, simple example of a dynamic page:

PHP Code:
<!doctype html>
<html>
<head>
    <meta charset="UTF-8">
    <title>Simple, Dynamic PHP</title>
</head>
<body>
    <form>
        <p>
            <label>What's your name? 
                <input name="visitor_name">
            </label>
            <input type="submit" value="Tell Us!">
        </p>
    </form>
<?php
    if( !empty( $_GET['visitor_name'] ) ){
        $visitor_name = htmlspecialchars( $_GET['visitor_name'] );
    }else{
        $visitor_name = 'Guest';
    }
    echo "
    <p>Welcome to my Simple, Dynamic Website, $visitor_name!</p>";
?>
</body>
</html>
...and everything works great.

The next fancy thing you might do is try to remember the visitor's name during their entire visit:

PHP Code:
<!doctype html>
<html>
<head>
    <meta charset="UTF-8">
    <title>Simple, Dynamic PHP</title>
</head>
<body>
    <form>
        <p>
            <label>What's your name? 
                <input name="visitor_name">
            </label>
            <input type="submit" value="Tell Us!">
        </p>
    </form>
<?php
    session_start();
    if( !empty( $_GET['visitor_name'] ) ){
        $visitor_name = htmlspecialchars( $_GET['visitor_name'] );
        $_SESSION['visitor_name'] = $visitor_name;
    }elseif( !empty( $_SESSION['visitor_name'] ) ){
        $visitor_name = $_SESSION['visitor_name'];
    }else{
        $visitor_name = 'Guest';
    }
    echo "
    <p>Welcome to my Simple, Dynamic Website, $visitor_name!</p>";
?>
</body>
</html>
Looks great, right? You didn't change anything, just added a few lines to save the visitor's name to the PHP session. However, when you run this new script, you get a broken page (maybe with a warning):
Quote Originally Posted by PHP
Warning: session_start() [function.session-start]: "Cannot send session cookie - headers already sent by omg What does this even mean My SCRIPT IS BROKEN whatamigoingtodo omgomgomg type in www.dynamicdrive.com NEED HLP PLZ PHP BROKE URGENT!!!?!!!!!!
You didn't even finish reading that, did you? (You should, and for so many reasons.)

So, what happened?

You wrote this in a straightforward, logical order:
  • DOCTYPE and HTML <head>
  • The <form> to get the visitor's name
  • The PHP stuff to write the welcome message
  • The closing HTML tags


Yes, that's the order that the HTML page goes in, but it's not the order that things actually happen in:
  1. PHP script executes, on your server
  2. PHP sends the script output to the visitor's browser

This hints at THE FUNDAMENTAL CHANGE you made to your webpage, probably without realizing it:

.........This Is No Longer HTML. None Of It.
.........You are writing PHP.
.........PHP is writing HTML.

It's not a webpage any longer; it's a program. It makes a webpage. Even if you simply change the extension on your webpage to .php, without adding one opening <?php tag anywhere, it's now a program, not a webpage. Things now happen in PHP order, not HTML order. Even when you "close" PHP by using the ?> tag, PHP doesn't really "close": it just takes everything you wrote, up to the next <?php tag, and treats it as if you'd written echo "all that stuff";.

What's the solution? A lot of new coders struggle with this (or similar) problems, sorting things out by trial and error. Even many coders who make their living as Web Designers, and have a few years' experience with PHP, never really figured out what the solution was: they just built habits that happened to avoid most problems. When the problem surfaces again, they'll still be stumped by it.

Separation of Concerns

The solution is, for lack of a simpler term, to do things "in PHP order." If you can untangle your PHP from your HTML, your program will be easier to understand and less error-prone. The big, bad programming world calls this "Separation of Concerns" - meaning, simply, that your code shouldn't be tangled up. There's a lot more to it than this, but to start with, just know:

  1. All of your PHP code, programming logic, functions, variables, whatever, need to come first.
  2. All of your output needs to go last.


There are several (good) ways to rewrite those earlier examples:

PHP Code:
<?php // PHP first!
$message = "Hello World";
?>
<html>
<head>
    <title>My First PHP Page</title>
</head>
<body>
    <?= $message ?>
</body>
</html>
This treats the HTML part of the page as a "template." The only processing we're doing is creating a message. The <?= tag (available always since version 5.4; only if `short_tags` are turned on in earlier versions) is specifically for templating: it means <?php echo $variable; ?>.

It may seem like unnecessary extra work, but we've now separated our program from its output - this is only a bit more complicated to start, but prevents a lot of problems from ever showing at all up later on. So, do you prefer:
  1. really easy now => more confusion later
  2. fairly easy now => less confusion later

?

But wait; here's an even better way:

PHP Code:
<?php // PHP first!
$message = "Hello World";
$HTML = "
<html>
<head>
    <title>My First PHP Page</title>
</head>
<body>
    $message
</body>
</html>";

// all done
echo $HTML;
?>
Now, there's only one point where there's any output, and it's at the very end. There's no wishy-washy-switching-back-and-forth between <?php and <html> at all. More importantly, you understand what you're doing just a little bit better.

If your program:
  • has <?php at the very top,
  • has only one part that generates output,
  • that part is at the very end, and
  • you can write exit; afterwards without affecting anything


...you've got the makings of a pretty good program. (Assuming, of course, it also throws no fatal errors.) As a bonus, it won't cause as many problems when you start to make your programs more complex.

Speaking Of Which

PHP Code:
<?php
// it works up here
session_start();

// let's get the visitor name from a function (see bottom of script)
$visitor_name = get_visitor_name();

// build our HTML
// this type of string definition is called a "heredoc" - 
//   it's very useful for writing large chunks of HTML because you can use quotes freely.
// a heredoc starts with three less-than (<) brackets, a space, and an opening token:
$HTML = <<< HTML
<!doctype html>
<html>
<head>
    <meta charset="UTF-8">
    <title>Simple, Dynamic PHP</title>
</head>
<body>
    <form>
        <p>
            <label>What's your name? 
                <input name="visitor_name">
            </label>
            <input type="submit" value="Tell Us!">
        </p>
    </form>
    <p>Welcome to my Simple, Dynamic Website, $visitor_name!</p>
</body>
</html>
HTML
; // a heredoc ends with a matching token, followed by a semicolon.


// all done
echo $HTML;
exit; // works!

// define a function that gets the visitor's name
//   (function definitions are "okay" after output):
function get_visitor_name(){
    if( !empty( $_GET['visitor_name'] ) ){
        $visitor_name = htmlspecialchars( $_GET['visitor_name'] );
        $_SESSION['visitor_name'] = $visitor_name;
    }elseif( !empty( $_SESSION['visitor_name'] ) ){
        $visitor_name = $_SESSION['visitor_name'];
    }else{
        $visitor_name = 'Guest';
    }
    return $visitor_name;
}
Questions? Ask. Late.

- Adrian ]]> traq http://www.dynamicdrive.com/forums/entry.php?267-Every-PHP-Tutorial-Is-Wrong