Query7 » Kishore Nallan

Using Facebook Connect for your web application

Kishore Nallan — Wed, 13 Jan 2010 17:53:11 +0000

With the exponential growth of Facebook over the past few years, it’s safe to say that quite a large number of active web users today own and use a Facebook account regularly. Facebook connect, which Facebook launched late 2008, is a set of APIs which allow you to integrate your users’ Facebook profile into your web application. Apart from allowing your visitors to login to your site using their Facebook identity (hence negating the registration process), it also allows you to leverage on the various social features of Facebook. Let’s take a overview of Facebook Connect, and how we can integrate it into our web application.

Facebook APIs

Facebook provides both RESTFUL and Javascript APIs. A great number of client libraries are available for creating your web application, though Facebook provides official support for only a handful of them. We will be using Facebook’s official PHP 5 client and Javascript libraries.

FQL and XFBML

Before we look delve deeper into Facebook connect integration, let’s look at FQL and XFBML – the two essential components of the Facebook connect platform.

FQL (yes, Facebook Query Language!) allows you to query data from Facebook easily using a SQL like syntax. This can be a substitute to invoking specific API methods using the client library. As a quick example, if we want to retrieve the name of a particular user, we could do:

SELECT name FROM user WHERE uid=12345

Simple isn’t it? It’s important to note here that though FQL is very similar to SQL, it doesn’t fully conform to all aspects of SQL that you might come to expect. Take a look at the FQL documentation to find out about syntax support, and the various tables provided by FQL.

XFBML is a markup language provided by Facebook which allows you to embed Facebook based widgets and information into your page. By using XFBML tags, it’s much easier to embed information into the page, than having to query for it first (using FQL or an API call) and then displaying it in the application. For example, to display the user’s name, we do that simply by using the tag:

With the basics out of the way, let’s get started on building a simple Facebook connect application using PHP.

Getting the API key

The very first thing you need to do when you are looking to make use of Facebook Connect is to apply for an API key. To get that, you need to sign in to the Facebook Developer app and create a profile for your web application.

Once you have chosen a name for your Facebook Connect application, and create the application, a profile will be created for your connect application within the Facebook Developer app. You can edit this profile to add in additional information about your application. Also, note that Facebook provides you with an API Key and a Secret, both of which you need to use while calling any FB Connect API method (for authenticating your request).

Although there are many fields, options and settions, you just need to provide Facebook with the URL of your Facebook Connect application, and you can get your application up and running! This can be done by clicking on the “Connect” link and filling in the “Connect URL” field:

When you are testing your application, it’s a good idea to place it under a sandbox such that only the developers have access to it. You can do that by going to “Advanced” tab and enabling the sandbox mode:

That’s it, we are ready to use Facebook Connect!

Creating the web app

Our sample Facebook Connect application will be really simple. Here’s the link to the demo (login using you FB account).

When the user visits the web app, we detect whether the user is already signed into Facebook. Facebook uses a single-on system – which means that if the user is alreadt signed into his Facebook account, we can detect that in our web application, and we can directly send the user along to the internal pages. In case the user is not logged in onto Facebook, we will give an overview of what our web application is about, and ask the user to login using Facebook Connect. Once the user is logged in, we will just display a list of his friends.

There are various ways of achieving this, but we will be using a mixture of XFBML, FQL and API calls to illustrate those concepts.

In our index.php, what we first need to do is to include the the official PHP client library for the REST API provided by Facebook. If you have not already download the PHP library, download it right here.

require_once 'facebook-platform/php/facebook.php';

The file facebook.php contains a class that we will be using to make all our Facebook API calls. As I have already mentioned, the API Key, and the Secret (which we obtained during the application registration above) are compulsory parameters for all API requests. So, for convenience, we can store this information on a config.php file, which we can include from all our application pages.

// config.php
// enter your application's API key and secret here:

$ApiKey = '12345667890';
$AppSecret = 'ABCDEFGHIJKLMNOPQRST';

Ok, with that out of the way, our next step is to initialise the Facebook class:

$facebook = new Facebook($ApiKey, $AppSecret);

If your $ApiKey and $AppSecret credentials match, we will subsequently be able to make calls to the Facebook API invoking the methods of the $facebook object. As we have discussed, we need to first check if the user is already logged into Facebook. We do that by checking the ‘user’ property of the $facebook object is set. If the user is logged in, $facebook->user will contain the logged in user’s Facebook ID.

if( !$facebook->user )
{
   // the user does NOT have a valid Facebook session
   // (i.e. not logged onto Facebook)
   // we will show some information about our app and ask the user
   // to login using FB connect:

   echo 'Hey, this application will list all your friends on Facebook!
                But, you need to login using your Facebook account
                to continue!';
   echo '
           ';
}
else {
   // show the user's list of friends (let's use FQL for this):

   $fqlQuery = "SELECT name FROM user WHERE uid IN (SELECT uid2 FROM
                       friend WHERE uid1 = $facebook->user)";
   $fbFriends = $facebook->api_client->fql_query($fqlQuery);

   if( $fbFriends == NULL )
   {
     echo "Oh no, you don't have any friends on Facebook! ";
   }
   else {
     echo "
Your friends are: ";
     foreach ($fbFriends as $fbFriend)
     {
       echo $fbFriend['name'] . "
";
     }
   }
}

The above code block encompasses most of our simple application logic! It also goes to show how straightforward Facebook Connect really is, once you get the hang of it. We have used both FQL and XFBML in the code snippet. Let’s break it down and see what each code segment does.

echo '
               ';

We are using XFBML above to render a Facebook connect login button for users who are not presently logged in. This button, when clicked, will open a pop-up window, which will allow the users to enter their Facebook credentials and log in.

Once they login, the current page will automatically refresh, and since the user has a valid Facebook session this time, $facebook->user will return the user’s Facebook ID. To enable XFBML, we need to include two Javascript snippets to be embedded onto the page:

FeatureLoader.js.php is a lightweight file that helps bootstrap the rest of the Connect library. It’s required for any XFBML functionality, and must be placed before any other Facebook Connect scripts or API calls. We can either place it in the HEAD tag, or right after the BODY tag.

The other Javascript snippet that’s needed is:

This code snippet can be placed anywhere after the FeatureLoader.js.php. The snippet enables the use of XFBML. The file xd_receiver.htm creates a Cross Domain Communication Channel between third-party Web pages and Facebook pages. We need to create a xd_receiver.htm page with the following contents, and place it in the same directory as the main index.php file:




    Cross-Domain Receiver Page

For logged-in users, we use FQL to retrieve the user’s friends.

$fqlQuery = "SELECT name FROM user WHERE uid IN (SELECT uid2 FROM
                         friend WHERE uid1 = $user)";
$fbFriends = $facebook->api_client->fql_query($fqlQuery);

$fbFriends will return a NULL, if no result is found. If the query produces results, an array of resulting users is returned. We can traverse this associative array and retrieve the various properies which we have queried for. In our case we have only queried for ‘name’, so we can print the names as:

foreach ($fbFriends as $fbFriend)
{
    echo $fbFriend['name'] . "
";
}

Of course, we can retrieve lots of other details about the users (including a URL to a profile picture).

With that, we come to the end of our quick Facebook connect tutorial. Although our sample application is ridiculously simple in functionality, and we only scratched the basics of the Facebook Connect platform, Facebook Connect does allow developers to harness the full power of Facebook’s social features right from our application. You should check out the Facebook API documentation, and follow their development blog if you are serious about going for deeper levels of integration with Facebook.

You can download our demo files here.

Writing web applications with CodeIgniter – Part 3

Kishore Nallan — Mon, 26 Oct 2009 05:06:29 +0000

We built a simple to-do list application last week by implementing the CI basics we learnt in first part of this tutorial. Today, let’s go over some of the things that will allow you to customise and extend the CI framework for your specific needs.

Changing the default URL routing

As we have already seen, CI parses the URLs in the following format:

example.com/className/functionName/variable1/variable2

While this suits most of the times, sometimes we might want to tweak CI to handle things different. With a reference to the blog example we saw in the first part, say, we want to display the entries of a blog by accessing a URL along the lines of "example.com/post/postID". Here, we actually want the "postID" to be parsed as a variable rather than a function name.

CI allows us to make such tweaks by allowing us to write our own routing rules. These rules are defined in application/config/routes.php file in an associative array called $route . The key of the associative array will define the URI to be matched, and its corresponding value will be the destination URI to which the request to be routed to. Apart from providing two wildcard types ":num" (matches only number) and ":any" (matches any character), CI also allows you to use regular expressions to define the URI to be matched.

For example, to achieve the routing we discussed above, we simply do:

$route['post/(:num)'] = "post/show_post/$1";

The above rule routes any request to the URL "post/postID" (where postID is a number), to the standard CI URL "post/show_post/$1" where show_post is a function of the post controller class.

Graceful error handling

CodeIgniter allows you to generate custom error messages, which calls specific error templates.

CodeIgniter automatically shows a 404 error message for a missing controller. But, for generating a custom 404 error message for a missing page internally, we can do that by calling:

show_404('path_to_missing_page');

One place where you might be needing this is when you are serving images via a controller that parses the image ID passed as a paramter and fetches it from a secure storage to display it. The template for the 404 error page is found in application/errors/error_404.php file.

If you want a more generic error message, you can use the show_error function for that. We can specify both the error message, and the HTTP status code when we call this function. For example,

show_error('Hey, this is a 500 error message!', 500);

The template for this error message is found in application/errors/error_general.php file.

Managing multiple applications

Although so far, we have used CI to handle just a single application, we can indeed have multiple applications using the same CI installation. To do this, we need to create a folder for each of our applications – currently our application resides within the "application" folder. So, say we have two applications called "app1" and "app2", we can structure the folders this way:

path_to_codeigniter/app1/
path_to_codeigniter/app2/

Copy the contents of the "application" folder (containing the views, controller, etc.) to these new folders. In addition, each of our application will need an "index.php" file that defines the path to the system and the application folders. So, we have to copy the "index.php" file from CI’s root folder to the app1 and app2 folders, and change the $system_folder and $application_folder variables to:

$system_folder = "../system"; 
$application_folder = "../app1";    // (use "../app2" for app2)

Caching

To achieve better performance, it’s important we use caching effectively. This is especially true for high traffic, content oriented websites. To reduce the strain on our server, CI allows us to serve a static version of a page. Caching can be enabled on a per-page basis. Once we have enabled caching for a page, the first time the page is loaded, a static version of the file will be stored in system/cache folder. On subsequent page refreshes, this static version of the page will be served.

To enable caching of a particular page, we simply call this function from a controller:

$this->output->cache($num_minutes);

$num_minutes defines how long (in minutes) we want the cached page to be served. The function can be called from anywhere within your controller. One the $num_minutes has expired, a new version of the cached page will be written to the cache.

Benchmarking your application

If you are interested in measuring the performance of various parts of your application, CI’s benchmarking class will be handy. The benchmarking class is automatically loaded by CI. To calculate the elapsed time between two points, we simply do:

$this->benchmark->mark('time_start');  // start timing

 //...all the code goes here...

$this->benchmark->mark('time_end'); // end timing
echo $this->benchmark->elapsed_time('time_start', 'time_end');

To find out the total elapsed time, we can use the same elapsed_time function without any parameters:

echo $this->benchmark->elapsed_time();

Extending CI’s helper classes

CodeIgniter provides various helper classes, some of which we used in our to-do list application. To extend (redefining existing methods or adding new methods) a helper class, we have to create a file in the application/helpers folder with the exact name of the existing helper class (in the system/helpers folder), but prefixing it with a "MY_". So for e.g., if we want to extend the URL helper class (which is named url_helper.php), we have to create a file named "MY_url_helper.php" in the application/helpers folder.

Once we have done that, we can add either new methods to the file, or redefine an existing method (by using the same function name and parameters), which will then over-ride the default method defined in the helper class.

Beyond CodeIgniter - Kohana framework

Although CodeIgniter is an extremely agile and light-weighted framework, CI’s support for PHP 4 means that quite a few "hacks" were used to make it work in PHP4. With the emergence of PHP5, many of these hacks (such as for auto loading of classes), have become unnecessary as PHP5 supports them cleanly, out of the box. Kohana, which began as a fork of CodeIgniter, is a PHP framework built exclusively for PHP5. It is also an entirely community driver project (unlike CodeIgniter, which is managed by EllisLab). If you don’t need support for PHP4, you really should take a look at Kohana. It’s very similar to CodeIgniter, and you should not have too much trouble finding your feet in it.

With that, we come to the end of our three part series on CodeIgniter. If there is something I have left out, or was unclear about, please do mention them in the comments.

Writing web applications with CodeIgniter – Part 2

Kishore Nallan — Mon, 12 Oct 2009 11:01:45 +0000

Last week, we covered the basic structure of a CodeIgniter application. Let’s now jump right into developing a simple todo list application using CodeIgniter. We will be keeping the actual functionality of the application itself simple here, as the goal here is to give a good overview on what it takes to build a CI application from scratch.

Okay, the first thing you have to do is to download and extract the latest build of CodeIgniter. Next, download the controllers, models and views that I have used in this sample todo list application. You should refer to these files as you read the tutorial. Here is the demo of the sample application (use “demo” as username and password).

Directory structure

All the files related to our application will be placed in the "system/application" folder:

As you can see, we have to place our controllers, views and models in their correspondng /controllers, /views and /models directories. Initially, we will have a sample controller (Welcome) in the /controllers directory, and its corresponding Welcome view in the /views directory. The model directory will be empty.

The /config directory consists of various files which will help us fine-tune the CI framework to our development environment. We will ignore the other directories in the /application directory for the time being.

Some basic configuration first

We need to modify some of the configuration files in the /config folder to set up the framework:

database.php – this is where we will be filling up our database connectivity details. The file has ample comments to help you fill in all the necessary details correctly!
config.php – we have to fill in the path to our CI root folder here in the variable: $config['base_url']
autoload.php – this file allows us to autoload any libraries or helpers that CodeIgniter provides us so that they are available across the entire system. We will be using the session library and the url helper class, so initialise the $autoload['libraries'] and $autoload['helper'] variables to:
- $autoload['libraries'] = array(‘database’,'session’);
- $autoload['helper'] = array(‘url’);

By default, all CI URLs will have a ".index.php" included in them. E.g. example.com/index.php/blog/edit

To remove this, we can optionally place a .htaccess file in your CI root folder with the following content:

RewriteEngine on
RewriteCond $1 !^(index\.php|images|css|scripts|robots\.txt)
RewriteRule ^(.*)$ index.php/$1 [L]

With the above rule in place, all requests other than those for index.php, images, css, scripts and robots.txt are treated as a request for your index.php file.

CodeIgniter session class

Before we go further, let’s have a brief review of CodeIgniter’s sessions class, which will be using in this application to keep track of the user’s session. CI’s session class can handle user session data stored using either cookies or in a database. CodeIgniter’s session class does not utilize native PHP sessions. To make use of the session class in our application, we must either initialize it in a controller’s constructor, or we have to auto-load it so that it will run in the background, and will be available for us across the entire system. To load the session class manually in the controller’s constructor, we do that by calling:

$this->load->library('session');

To auto-load the session class, we have to open the file "application/config/autoload.php" and add the item to the "autoload" array as I have mentioned in configuration step above.

Reading and writing data to the session class is a breeze! To write data to a user’s session, we simply do:

$this->session->set_userdata('some_variable', 'some_value');

And, to retrieve the data again, we just call:

$item = $this->session->userdata('item');

Apart from that, CI’s session class by default, provides us with the following information:

user’s unique Session ID
user’s IP Address
user’s User Agent data (the first 50 characters of the browser data string)
user’s "last activity" time stamp

Our application features:

With that, out of the way, let’s get started. Our to-do-list application will have the following "features":

a simple user sign up and login system
session management using CI’s session class
a single to-do list which allows multiple users to add and delete items using AJAX

Database schema

Given the rather simple nature of our application, it’s not too difficult to identify what database tables we will be needing upfront. We will need two tables:

users : stores the user id, username and the hashed password.
items : stores the to-do list items and their attributes like item_id, user_id (ID of the user who created it)

CREATE TABLE IF NOT EXISTS `items` (
 `item_id` bigint(20) NOT NULL auto_increment,
 `user_id` bigint(20) NOT NULL,
 `item_text` varchar(255) NOT NULL, `is_done` int(11) NOT NULL,
 PRIMARY KEY  (`item_id`)
 ) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE IF NOT EXISTS `users` (
 `user_id` bigint(20) NOT NULL auto_increment,
 `username` varchar(100) NOT NULL,
 `password` varchar(100) NOT NULL,
 PRIMARY KEY  (`user_id`)
 ) ENGINE=MyISAM DEFAULT CHARSET=latin1;

Setting up the above tables in the database which you have mentioned in your database.php configuration file above.

Here is a breakdown of all the controllers, views and model we will be needing for this application. I will explain the purpose of each of them, as we go about tackling them.

The login controller

The login controller first checks whether the user is already logged in – in which case, we simply redirect him to the dashboard. This, we do by checking whether the "logged_in" field exists in the user’s session data. We are using CI’s session class for this:

if( $this->session->userdata('logged_in') )	// user already logged in
{
	header("Location: " . base_url() . "index.php" );
	die();
}

The login controller serves two needs:

render the login form initially for a user who wants to sign in to the system
when the user submits the login form, authenticate the user and either redirect him to the dashboard or show an error message

When the controller is called, we can find out whether we should render the login form, or treat the request as a login form submission by checking for the POST variable ‘login’, which is the name of the "login" submit button in the login form.

if( $this->input->post('login') )
{
	// treat this as a login form submission
}

else {
	// render the login form
}

If it’s NOT a login form submission, we simply load the login_view defined in application/views/login_view.php. This file will render the login form.

On the other hand, if its is a login form submission, we first retrieve the username and password variable from the POST request. We then load the Users_model class, and use its validate() function to authenticate the user. If the user’s username and password match, his user_id field from the database is returned. Else, a -1 is returned. For a valid user, we initialise his session by:

$newdata = array(
 'user_id'  => $user_id,
 'username'  => $username,
 'logged_in' => TRUE
 );

 $this->session->set_userdata($newdata);

We then redirect him to the dashboard. If the username and password provided do not match, we load the login_view by passing a variable ‘$message’ that contains the error to be displayed.

The Dashboard

The welcome controller is the default controller for CodeIgniter. It will already be found in the /application/controllers directory, and this is the controller that will be called when you access our application’s URL directly without using any URL segments, as discussed in the previous article. Let us just make use of this controller for our application’s dashboard. Assuming the user has already logged in successfully, let’s build our application’s dashboard – the page the visitor first sees after logging in. In our case, it will be a page which will display a set of to-do items, and in addition, provide a way to enter a new to-do item or modify the done/not-done status of any existing item using AJAX. Here is the index() function of the welcome controller.

function index()
{

	if( !$this->session->userdata('logged_in') )	// user NOT logged in
	{
		header("Location: " . base_url() . "index.php/login" );
		die();
	}

 	$this->load->model('items_model','items');
        $data['all_items'] =
$this->items->fetch_all_items($this->session->userdata('user_id'));
 	$this->load->view('dashboard_view',$data);
 }

The welcome controller will check whether the user is logged in (using the session data set earlier in the login controller). If the user is not logged in, or his session has expired, we will redirect him to the login page. The base_url() function belongs to the URL helper that we autoloaded in our configuration, and it returns the base URL of our application (including the "/" at the end of the URL). Otherwise, we will load the Items_model class which will be used to interact with the items table in the database. The fetch_all_items() function of the item_model class will fetch all the todo items of this particular logged in user from the "items" table. The only other thing to note here is that we are using the session class to retrieve the user id of the user that we have stored as session data when the user successfully logs in to the system.

function fetch_all_items($user_id)
{
  // fetch the to-do items of the user identified by $user_id:
  $query = $this->db->query("SELECT * FROM items WHERE user_id = $user_id");
  return $query->result();
}

The index() function of the Welcome controller then loads the view "dashboard_view", defined in "dashboard_view.php" in the system/application/views directory. When the view is loaded, we are passing to it the todo items we fetched from the database using the Items_model class. The view then renders all the to-do items on the page.

dashboard_view.php links to an external stylesheet (todoapp.css) and a JavaScript file (todoapp.js). The AJAX functionality is defined in the JavaScript file. In our application, we are using AJAX to add a new todo item to the list, and also update the done/not-done status of any of the todo items. The function addNewItem() in the JavaScript file is bound to the click event of the "Add" button.

The addNewItem() function, when fired, makes an AJAX POST request to the "add" controller which will handle the addition of a new todo item. The add controller will return the ID field of the newly added todo item in the database. If the operation is a success (if the ID returned in not -1), we simply append the new todo item (along with a checkbox) to the bottom of the existing items. We also clear the text in the textfield.

The updateItem() function is bound to the click event on each of the checkboxes. When fired, it checks whether the checkbox that the user clicked is selected or not, and it sends this information to the "update" controller.

The add controller

In all the controllers, we will have to first check if the user is logged in, before we carry out any action. For a valid user, we retrieve the text of the new todo item to be added (from the POST variable sent to the script) using:

$this->input->post('item_text',TRUE)

The second parameter is set ‘TRUE’ to indicate that the input must be filtered to negate XSS (cross site scripting) attempts. XSS is a major problem faced by many web applications, and as a golden rule, any input which might potentially get rendered on the front end must be passed through an XSS filter that escapes/strips out the dangerous elements. As an added precaution we also check whether the todo item’s text is not empty, and if all is clear, we load the "Items_model" class once again, and call the add_item() function to add the todo item to the database. The add_item() function uses another handy function that CI provides, to escape the data by adding single quotes around the data:

$item_text = $this->db->escape($item_text);

The update controller

What the update controller does is similar to the add controller and also fairly straight forward. It simply retrieves the POST variables sent to it (the ID of the item which is to be updated, and its updated status). The update controller then loads the Items_model and invokes the update_item() function to peform the update.

The logout controller

The logout controller destroys the session data of the user, and then redirects him to the login page once again.

$this->session->sess_destroy();
header("Location: " . base_url() . "index.php/login" );

User registration

Finally, let’s get to the user registration, which is handled by The Register controller. First off, I should mention here that for the sake of simplicity, I have implemented a very simple registration form, with absolutely no spam control!

The Register controller is similar to the Login controller in that – it again serves both the purposes of rendering the registration form, and as well as handling the form submission. The register_view simply asks the user to pick a username and password. The

’s action attribute points to the URL of the register controller.

When the form is submitted, the Register controller first checks to see that both the username and password fields are not empty. It then loads the "Users_model" which handles all database operations concerned with the "Users" table. We will invoke the is_valid_username() of the Users_model to see whether the username that the user has chosen already exists (the function returns a -1 if no such username is found on the system). If it a username is indeed found (in which case the function will return the ID of the user), we will initialise a $message variable with the text "That username already exists." and load the register view again, by passing the $message variable for rendering.

if( $this->users->is_valid_username($this->db->escape($username)) != -1 )
{
	// username already exists
	$data['message'] = "That username already exists.";
}
...
$this->load->view('register_view', $data);

If the user has chosen a non-existing username, then we go ahead and add the user to the database by calling the Users_model’s add_user() function, by passing the username and his hashed password. We are simply using a plain SHA1 hash here to store the password (which is again considered not secure enough without salting, but enough for our simple application). Once the user is added to the MySQL database, we use the nifty "mysql_insert_id()" PHP function to retrieve the auto increment ID field of the user row just added to the "users" table. After a successful account creation, we initialise the user’s session and redirect him to the dashboard, so the user can start using the application right away.

With that, we come to the end of this second part of CodeIgniter tutorial.

Writing web applications with CodeIgniter: Part 1

Kishore Nallan — Tue, 29 Sep 2009 15:20:42 +0000

CodeIgniter is a PHP framework that makes writing secure web applications a breeze. Being extremely light weighted, it’s an impressive toolkit which promotes the Model-View-Controller (MVC) approach to software development. CodeIgniter’s incredibly useful libraries, helpers and simplicity give you a sound foundation to quickly build your web apps on. This will be the first part of a series of tutorials focusing on CodeIgniter. Today, let’s get started with the basics of CodeIgniter and familiarize ourselves with the structure and semantics of a CI application.

I am assuming that you are already familiar with the MVC pattern, so let’s briefly see how it applies to a typical CI application.

View – A view is simply the content which a user sees rendered on a any page. It can be either a full web page, or even code snippets like the header or the footer of a web page. The view’s primary aim is to render data on the screen, which will be passed to it by a controller.

Controller – A controller handles the actual application logic. It acts as an intermediate between the View (front end) and the Model (the data). The controller, typically fetches records from a database via a model class, and then passes it to a view for rendering.

Model – A model is concerned with reading and writing data to and from a data souce – in our case, a database. It essentially consists of functions which help you isolate database operations from your core application logic. In CodeIgniter, a model is not necessary, should you wish to manipulate the database from a controller itself.

The URL structure

One great thing about CodeIgniter is that it generates URLs which is search engine friedly and also extremely logical for programmers. Instead of using query strings (like index.php?action=display&id=223) to pass variables, it uses a very semantic segment based URL structure. By default, the CI URLs are parsed this way:

example.com/controller_class_name/function_name/ID1/ID2

As we can see, the first segment of the URL refers to the name of the controller class, the second part referring to the function in the controller that should be invoked, and the subsequent parts representing various parameter values that can be passed to the function. Having understood that, it’s a good time to see the structure of a controller class.

Let’s take a simple example of a blog. Let us say we want a page where we want to show the entries of a blog, we can have a controller "show" which will be defined this way:

class Show extends Controller {

	function index()
	{
		// access a model class to fetch all the blog posts
			...
		// invoke a view and pass to it the blog posts to render
	}
}

There are a couple of things to note here:

all controller classes begin with a capital letter in CI – i.e Show
we will be saving the above file as "show.php" – the file name is essentially the same as the class name, except that the class name’s first character has to be in capital case.
the index() function will be the default function of the class – much like your main() function in a C program!
you will access the above controller with the following URL: example.com/show/index or just example.com/show

Remember that the first segment refers to the controller name and the second segment refers to the function name. Since the index function is the default function for the controller, we can leave it out from the URL. We can add another function to the class, called entry – which will display a specific blog entry identified by an identifier:

function entry($entry_id)
{
	// access a model class to fetch the blog post with ID $entry_id
		...
	// invoke a view and pass to it the blog post to render
}

Now, to display a particular blog entry, we access the URL: example.com/show/entry/123 , where the "123" is (say) the ID of the blog entry to be rendered. Pretty easy, right ?

Now, let’s define a CI model class. Continuing with the same blog example, let’s say that the name of the model class which will handle our blog entries is "Entry_model":

class Entry_model extends Model {

	function Entry_mode()
	{
		parent:Model();
	}

	function fetch_post($entry_id)
	{
		// do your database query and return the record...
	}
}

Now, to invoke the method fetch_post() from the controller, we do:

$this->load->model(Entry_model');
$blog_entry = $this->Entry_model->fetch_post($entry_id);

Again, it’s very intuitive. We load the model class, and then, invoke a method from the model class which will return the blog entry record. The naming convention for the model class is the same as that for a controller – the class name should start with a capital letter. Thus, the above model class is called "Entry_model" and it will be defined in the file "entry_model.php".

Finally, let’s get to how CodeIgniter handles the View. As I have already stated above, CI is very flexible in how you want to define a view. A view can be a whole page, or page fragments like header, footer, navigation, sidebar etc. It’s always a good practise to logically break down the layout of a web page into a number of components, as it promotes code reusabilty.

As for now, for simplicity, let’s just say that our blog entry will be rendered using a single view. So, we will basically have a .php file that contains the structure (design) of the blog and which will display the blog entry that is passed to it from the controller through the form of variables. Let’s say our view (which display a blog entry) is called "entry_view.php":



Showing a blog entry



$entry_title";
	echo $entry_text;
?>

When we invoke the view from the controller, we will pass in the variables $entry_title and $entry_text. Here is how we invoke the view we have defined above from a controller:

$data['entry_title'] = "A blog post title";$data['entry_text'] = "Lorem ipsum dolor sit amet...";$this->load->view('entry_view', $data);

I have shown a very simple example of how data is passed from the controller to a view above. The variables that will be used in the view are defined as elements of an associative array. To load a view, we call it by its filename – we don’t have to use ".php" extension unless we are using some other extension for the view files.

With that, I have covered the basic skeleton of a CI application. Stay tuned for the next article, in which I will walk you through on how to build a simple application using CodeIgniter, and also cover some more advanced concepts along the way!

Creating an inline contact form

Kishore Nallan — Mon, 07 Sep 2009 10:41:50 +0000

Customer feedback is arguably one of the most critical factors determining the success of a product over a period of time. Hence, it’s not surprising that many websites have some form of contact form or another to encourage users to write back to them. Most of these “contact” pages tend to be on a separate page which is usually part of the navigation or is linked to with phrases like “we encourage your feedback” or “do get in touch with us”, etc.

However, I have often noticed that many people (unless they genuinely needed help), either back away from submitting their comments (when they are confronted by a large textarea on the contact page), or simply move away from the site as the contact page loads.

Today, let’s spice things up a bit by using jQuery to load a lightweight inline contact form. So, instead of loading a separate contact form page when the “contact us” link is clicked, we will just have a small textarea opens up dynamically right next to the link – so that the user can type his feedback and it can be submitted rightaway using AJAX. Our main aim here is to encourage more users to provide feedback and although I don’t have actual data to prove whether an inline form will be any more helpful, I have used it in a couple of places, and it did appear to bring in more casual feedback about the site, features etc. Ok, let’s get started. Here is the demo of how it will all look in the end.

Okay, first let’s have a hypothetical page in which we want to make use of the inline contact form. The call of action, is obviously the “We would love to hear your feedback” link, which has the id “a_inline_form”. Initially, this hyperlink will simply point to the default contact form page. We will have the inline form in a DIV with id “inline_form”, which will be hidden initially.

#inline_form {
		/* keep the inline form hidden initially */
		display: none;

		position: relative;
		padding: 10px;
		width: 260px;
	}

We will now use jQuery to “hijack” this link and fire our inline contact form into action:

 // toggle visibility of inline form when link is clicked
$("#a_inline_form").click( function() {

	$("#inline_form").toggle(200);

	$("#inline_form").css( "left", $("#a_inline_form").position().left +
                                                $("#a_inline_form").width() );

	$("#inline_form").css("top", "-40px");

	// get cursor to texarea, ready to receive keystrokes!
	$("#inlinecmt").focus();

	// return false to prevent default link behaviour
	return false;
});

The above code is fairly self explanatory – I just want to describe how we are positioning the inline form. jQuery allows us to very easily retrieve the left offset position of an element (even when it’s not absolutely or relatively positioned!) using “$(elem).position().left” property.

In this example, I wanted to place the inline form right next to the comment link. To do that, we can simply set the “left” CSS property of the inline form to a value that’s the sum of the left offset of the feedback link and the width of the comment link – this will of course place the inline form right next to the feedback link. In addition, we also set the cursor focus to the inline form so that the textarea is ready to receive input right away.

We have a simple “ok” button underneath the textarea which will be used to submit the form. We will once again “hijack” the form submit event using jQuery and perform the form submission using AJAX. I have omitted the actual form submission and processing here.

$("#inline_form").submit( function() {

	// make your ajax POST call here...

	$("#a_inline_form").after('Thanks for the comment!' +
                               '');
	$("#inline_form").hide(200);

	setTimeout( '$(".msg").hide()', 2000);

	// return false to prevent default form submission behavior
	return false;
});

Now, once the AJAX call is successful, we need to notify that to the user and thank him for the feedback. I have chosen to do that by inserting a message right after the feedback link and hiding it (using setTimeout() ) after 2 seconds. Don’t forget to hide the inline form too. With that, our inline form is up and ready to go!

This is by no means a replacement for the traditional contact form, but it will be handy in places where one requires casual feedback from users. And as you would have already noticed, we have used JavaScript here unobtrusively – so in case the user has JavaScript disabled, the feedback link merely loads the default contact page.

Avoiding long polling

Kishore Nallan — Sun, 26 Jul 2009 15:04:02 +0000

Right from Twitter to Google Wave, real time information streaming via the browser seems to be the most "happening" thing on the web arena currently. However, feeding real time information as and when it is available to an user using your web application is not as straight forward as it is on a desktop environment. HTTP is a stateless protocol which does not currently support a two way communication link between the server and the user’s computer via the browser.

The simplest way to simulate real time streaming of information is to poll the server every N seconds, and to display the information (if any). The number N will determine how real time the resulting stream of updates will look to a viewer. This model is simply called, polling. Now, polling is bad because it repeatedly connects and disconnects to the server, which when scaled across thousands of users, cause severe strain on your server. This problem becomes even more apparent in cases when the poller returns with empty data most of the times.

The jQuery snippet below polls the server every 3 seconds for new information and displays it in a simple alert box.

function callComplete(response) {
	alert("Response received is: "+response);
};

function connect() {
	// when the call completes, callComplete() will be called along with
	// the response returned
	$.post('/path/to/script.php', {}, callComplete, 'json');
};

$(document).ready( function() {
	setInterval(connect,3000);
}

Long polling

This technique is an optimisation of the traditional polling method. In long polling, once the client makes a connection with the server (via JavaScript), the server waits for the data requested by the client to become available. If it’s not immediately available, the server (being a PHP script for example) loops and sleeps. When the data is available, the server returns the data to the client and the connection closes. When this happens, the client again reconnects with the server (in the callback function of your original AJAX request).

This method is definitely an improvement over mindless polling, as we will avoid repeatedly opening and closing connections when data is not available for long periods of time. However, it is important to be aware of the server side technical limitations of long polling. Since connections might be kept alive for long durations of time, your web server must be capable of handling such large numbers of simultaneous connections. We talked about how certain light weight webservers outperformed Apache in this particular area in the last article.

Let’s look at a very simple jQuery/PHP long polling example:

function callComplete(response) {
	alert("Response received is: "+response);
	// reconnect to the server
	connect();
};

function connect() {
	// when the call completes, callComplete() will be called along with
	// the response returned
	$.post('/path/to/script.php', {}, callComplete, 'json');
};

$(document).ready( function() {
	connect();
}

In the PHP end, we do:

while(1) {

	$data = "some data fetched from the DB";

	// if we have new data, return it to the client
	if(!empty($data)) {
		echo json_encode($data);
		break;
	}

	sleep(3000);	// we sleep for 3s and check again for data
}

COMET streaming

COMET is a generic term that refers to the use a persistent HTTP connection for the web server to "push" data to the client as and when it arrives. If you have ever wondered how Gmail is able to notify you of a new email message seconds after it is sent, this is what they use to push the new email notifications to the front end.

However, as often is the case with JavaScript, the cross browser compatibility issues mean that a host of methods (targeting different browsers) are used to implement such an interaction. The upside is that these methods rely purely on JavaScript, and hence not dependent on any specific client side plugin. A detailed exploration of these different methods and their caveats is beyond the scope of this article, but let’s get a quick overview of these methods.

Hidden iframe technique: A hidden iframe html element is embedded onto the page, which points to the URL on the server which handles the persistent connection. The server will then push the data as it arrives to the iframe, using