Introduction to Laravel Framework

We will build a very simple guestbook application using plain vanilla PHP without a framework. We’ll create a new MySql database named “guestbook” and create the “entries” table:

CREATE TABLE `entries` (
        `id` INT NOT NULL AUTO_INCREMENT,
        `username` VARCHAR(50) NOT NULL,
        `email` VARCHAR(100) NOT NULL,
        `comment` TEXT NOT NULL,
        `date_added` DATETIME NOT NULL,
        PRIMARY KEY(`id`)
);

On to the PHP stuff. Below is the entire source code of the guestbook script:

$db_host = "localhost";
$db_database = "guestbook";
$db_user = "Your_Database_Username";
$db_pass = "Your_Database_Password";

// connect to database
$db_conn = mysql_connect($db_host, $db_user, $db_pass);
mysql_select_db($db_database, $db_conn);

$gb_entries = ""; // the string we'll append entries to

// if form is submitted, then insert into database
if (!empty($_POST["submit"])) {
    $username = $_POST["frmName"];
    $email = $_POST["frmEmail"];
    $comment = $_POST["frmComment"];
    $date = Date("Y-m-d h:i:s");

    $sql_insert = "INSERT INTO entries(username, email, comment, date_added) VALUES('$username', '$email', '$comment', '$date')";

    mysql_query($sql_insert);
    $num_rows = mysql_affected_rows();

    // See if insert was successful or not
    if ($num_rows > 0) {
        $ret_str = "Your guestbook entry was successfully added.";
    } else {
        $ret_str = "Your guestbook entry was NOT successfully added.";
    }

    // append success/failure message
    $gb_entries .= "
$ret_str

";
}

$sel_select = "SELECT username, email, comment, DATE_FORMAT(date_added, '%m-%d-%y %H:%i') date_added FROM entries";
$result = mysql_query($sel_select);
while ($get_row = mysql_fetch_array($result, MYSQL_ASSOC)) {
    $username = $get_row["username"];
    $email = $get_row["email"];
    $comment = $get_row["comment"];
    $date = $get_row["date_added"];

    $gb_entries .= "
$comment
Posted on $date by \"mailto:$email\">$username
";
}

// cleanup
mysql_free_result($result);
mysql_close($db_conn);
?>


    


     echo $gb_entries; ?>

     action=" echo $PHP_SELF;?>" method="POST">
         border="0">
            
                Name
                 type="text" name="frmName" value="" size="30" maxlength="50">
            
            
                Email
                 type="text" name="frmEmail" value="" size="30" maxlength="100">
            
            
                Comment
                 name="frmComment" rows="5" cols="30">
            
            
                
                 type="submit" name="submit" value="submit">
                     type="reset" name="reset" value="reset">
            
        
    

The guestbook application is ridiculously simple - it will display a form, collect some information from visitors and display the comments posted by them.

Here’s our guestbook app in action:

This PHP script combines all the logic and markup in a single file. This is not necessarily a best practice or modern programming technique in PHP, but it should be straightforward enough for any PHP developer to understand. With a single-page simple web app like this one, the write-it-from-scratch approach isn’t necessarily bad. For one thing, this code is simple to comprehend - even a novice developer can read and understand it fairly easily. But despite its simplicity, this approach has a number of problems and annoyances.

Ask yourself these questions:

• What happens when multiple parts of your application need to interact with the database? Surely that database-related code shouldn’t need to be duplicated in each and every PHP script. The prudent thing to do would be to refactor all database code into a shared PHP file.

• Should a developer really need to worry about opening and closing database connections, learn all the different data-access APIs for multiple database engines and memorize many different SQL dialects? This sort of boilerplate reduces programmer productivity, increases development time and introduces opportunities for bugs. The database-related tasks would best be handled by some database-agnostic, higher-level infrastructure that shields the developer from nitty-gritty of the underlying database implementation.

• What happens when your web app is deployed in multiple heterogenous environments, each with a separate database and credentials? At this point, some environment-specific configuration becomes essential.

• What happens when you develop your app using the MySql database, but your client wants to use PostgreSql instead? Should you go back and change all the mysql_* data-access APIs and SQL queries? The pragmatic thing would be to develop the application using database-agnostic libraries such the PDO. But that still doesn’t protect you from rewriting at least some of the SQL DDL and/or DDL queries.

• What happens when a HTML/CSS/Javascript designer who has no experience coding PHP wishes to redesign the page? Altering the files in wrong places could crash your entire application. Ideally, the business logic of the web app as well as the database-related code should be separate from the HTML view, so that a designer could edit the latter without affecting the former.

These problems are precisely what a web development framework intends to solve. A web framework provides a programming infrastructure for your applications, so that you can focus on writing clean, maintainable code without having to reinvent the wheel. That’s exactly what Laravel does!