If you’re going to be developing a multi-language site, then when you’re setting up your CMS, from the beginning be sure to go for a CodeIgniter CMS like CI-CMS or Pyro CMS in order to minimize languages issues down the road. {The Zend framework, with its strong partial rendering, may seem like a better option in a pinch, but CodeIgniter trumps Zend in other crucial areas, so it’s worth sticking with.}

With CodeIgniter it makes great sense to build in modular separation (you can find the library here), though at first glace I’ll agree it looks like a tough implementation.

As you scan the library article, the lines to put most emphasis on will naturally deal with switching languages.

For example, you’ll find in the Notes section of the above library site:

<?php

anchor($this->lang->switch_uri('fr'),'Display current page in French');
$lang['about.gender'] = "Je suis un homme";

?>

Plug the lines below into your route.php and config.php files.

In config/route.php :

<?php

$route['^fr/(.+)$'] = "$1";

$route['^en/(.+)$'] = "$1";

// '/en' and '/fr' URIs -> use default controller

$route['^fr$'] = $route['default_controller'];

$route['^en$'] = $route['default_controller'];

?>

In config/config.php,

$config['base_url']  must correspond to your configuration. For example,

<?php

$config['index_page'] = "";

?>

Creating the language file in system/application/language/english/about_lang.php was already clear to you.

<?php

$lang['about.gender'] = "I'm a man";
$lang['about.gender'] = "Je suis un homme";

?>

The controller part at

system/application/controllers/about.php should also be clear to you.

In the index function

<?php

$this->load->helper('language');

$this->load->helper('url');

// load language file‚

$this->lang->load('about');

$this->load->view('about');

?>

Once you’re done with these, browse to the welcome module on your local machine at http://localhost/ci/fr/welcome/test.
You should find the language lines show up as expected.

Be sure to hit the CodeIgniter resource site for some really useful, ready made down loadable translation files in zip format. This’ll save you heaps of time and work. Once you’ve extracted these zip archives, you’ll find files named as in the about_lang.php as above.

Next, while looking into partial rendering, we come across this site, which brings us more clarity.

<?php

$this->view->layout = 'master_layout_file'; // or leave this empty to render partials only

//Add a partial file and (optional) $data‚

$header = $this->view->load('header','header_file',$data);

// subheader‚

$header->load('sub_header','sub_header_file',$data);

$header->set($data);

$this->view->render();

?>

Now let’s render the partials in our master template:

<?php $header->render();?>;

And that’s about it. Pretty simple, right?

Before closing, just a brief note: PyroCMS is a multilingual CodeIgniter CMS with built-in language configuration options you can tailor to your site. You can find language settings inside the admin panel, and while the implementation will be similar to the approach we’ve outlined above it may not be an exact match.

Well, that’s it!  Thanks for reading, and I hope this helps.  If you have any questions about this specific tutorial or any other issues re: web development with CodeIgniter, Zend, or whatever else, drop us a line any time from our contact page!

Prakash R. Mohanty

Senior Software Engineer
Sourcebits Technologies

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:

<fb:name uid="12345" />

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 '<h2>Hey, this application will list all your friends on Facebook!
                But, you need to login using your Facebook account
                to continue!';
   echo '<fb:login-button onlogin="javascript:location.reload(true)">
           </fb:login-button>';
}
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 "<p>Oh no, you don't have any friends on Facebook! </p>";
   }
   else {
     echo "<h3>Your friends are: </h3>";
     foreach ($fbFriends as $fbFriend)
     {
       echo $fbFriend['name'] . "<br />";
     }
   }
}

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 '<fb:login-button onlogin="javascript:location.reload(true)">
               </fb:login-button>';

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:

<script src="http://static.ak.connect.facebook.com/js/api_lib/v0.4/
                            FeatureLoader.js.php" type="text/javascript">
</script>

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:

<script type="text/javascript">
 FB_RequireFeatures(["XFBML"], function(){
 FB.Facebook.init("YOUR_API_KEY", "xd_receiver.htm");
 });
 </script>

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:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
    <title>Cross-Domain Receiver Page</title>
</head>
<body>
<script src="http://static.ak.connect.facebook.com
                   /js/api_lib/v0.4/XdCommReceiver.js?2"
              type="text/javascript">
</script>
</body>
</html>

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'] . "<br />";
}

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.

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.

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 <form>’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.

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":

<html>
<head>
<title>Showing a blog entry</title>
</head>
<body>

<?php
	echo "<h1>$entry_title</h1>";
	echo $entry_text;
?>

</body>
</html>

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!

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 <script> tags. This content is then channeled to the parent window using JavaScript. This method is based on the fact that many browsers evaluate JavaScript chunks as they are received, even if the complete page has not finished loading yet. However this method is prone to cause the "loading" icon or status bar message to appear all the time (since we are using a persistent HTTP connection, the browsers tend to believe that the page is yet to finish loading fully).

XMLHttpRequest using Interactive readyState: This method is targetted towards Firefox, Safari and Chrome, which support the interactive readyState property of the XHR object, and fires events every time a chunk of data is received from the server.

Server-Sent events: This is a feature (from the WHATWG Web Applications 1.0 specification) supported by Opera since v9, using which we can push events from the server directly to the visitor’s browser. Refer to this article on how it’s used.

As you can see, it’s quite a mouthful, and hence implementing COMET streaming which works uniformly across all major browsers is not a task for the faint hearted (not forgetting that the webserver must also be able to handle a large number of persistent connection). The good news is that quite a lot of the hard work has already been done for you. There are various opensource COMET servers and client libraries which you can use to deploy a COMET application pretty safely. Here are a few of them for your exploration:

Orbited: "Orbited is an HTTP daemon that is optimized for long-lasting comet connections. Orbited allows you to write real-time web applications, such as a chat room or instant messaging client, without using any external plugins like Flash or Java. "

Cometd: "Cometd is a scalable HTTP-based event routing bus that uses a Ajax Push technology pattern known as Comet."

Meteor: "Meteor is an open source HTTP server, designed to offer developers a simple means of integrating streaming data into web applications without the need for page refreshes."

Comet Pi: This is a standalone JavaScript library which you can use to handle the various cross browser issues that COMET causes. You can use pi.comet with any serverside language.

As a result of the already proven TYPO3 CMS, the upcoming 5th version of the system is bringing a solid PHP framework, which can be used apart from the whole system for developing applications of any kind.

The FLOW3 subsite stats, against what’s commonly seen out there, FLOW3 is not a pick’n'mix store of motley components. It’s a framework which helps you with the infrastructure of your application. Object Lifecycle Management, Package Management, Resource Management and Security are on his home field. Real business logic is left over to third-party packages.

All the most common features we can find in other PHP frameworks are going to be provided by FLOW3, like MVC architecture, Validation, Filters, Persistence Object Manager and much more.

Next week, I’ll post a getting started with a simple application and provide my personal review of this framework, which – OMHO – is going to rock!

In PHP, the keyword “$this” is used as a self reference of a class and you can use it for calling and using these properties and methods as shown in the example bellow.

Create a file ClassOne.php with code bellow:
<?php

class ClassOne
{
    // this is a property of this class
    public $propertyOne;

    // When the ClassOne is instantiated, the first method called is
    // its constructor, which also is a method of the class
    public function __construct($argumentOne)
    {
        // this key word used here to assign
        // the argument to the class
        $this->propertyOne = $argumentOne;
    }

    // this is a method of the class
    function methodOne()
    {
        //this keyword also used here to use  the value of variable $var1
        return 'Method one print value for its '
             . ' property $propertyOne: ' . $this->propertyOne;
    }
}

In this class, we are also using the visibility declarations (public), which means whether the members are accessible on a subclass – we will discuss it later – or instance.
Another thing you must be curious about is the use of ‘->’. This is an object pointer and, on PHP, it’s used for accessing members inside an object.

Now, let’s test your class! Create another file, called use.php with the following code:
<?php

// include your class file
require_once 'ClassOne.php';

// Create an instance of your class
$classOneInstance = new ClassOne('Hello');

// And test it
print $classOneInstance->propertyOne . '<br />';
print $classOneInstance->methodOne();

- Note that in both files we’re not using the enclosing PHP tags (?>). Once they have only PHP code, it’s not needed and it’s also a good practice to avoid them on pure PHP files.

<?php

class Custom_Http_Request
{
    private $_url;
    private $_body;
    private $_method = 'POST';
    private $_headers = array();
    private $_response;
    private $_stream;

    public function __construct($url, $body)
    {
        if (empty($url) || empty($body)) {
            throw new Exception('Both URL and BODY are required '
                              . 'for fetching the request.');
        }

        $this->_url  = $url;
        $this->_body = $body;
    }

    public function setMethod($method)
    {
        if ('POST' == $method || 'GET' == $method) {
            $this->_method = $method;
            return $this;
        }

        throw new Exception('Invalid method set.');
    }

    public function addHeader(array $header)
    {
        if (!empty($header)) {
            $this->_headers[] = $header;
            return $this;
        }

        throw new Exception('The headers are empty.');
    }

    public function getMethod()
    {
        return $this->_method;
    }

    public function getBody()
    {
        return $this->_body;
    }

    public function getHeaders()
    {
        return $this->_headers;
    }

    public function getResponse()
    {
        if (is_null($this->_stream)) {
            $this->_openStream();
        }

        if (is_null($this->_response)) {
            $this->_response = @stream_get_contents($this->_stream);

            if (false === $this->_response) {
                throw new Exception('It is not possible to '
                                  . 'read from the response.');
            }
        }

        return $this->_response;
    }

    private function _assemble()
    {
        $params = array(
        	'http' => array(
        		'method'  => $this->_method,
        		'content' => $this->_body
            )
        );

        if (!empty($this->_headers)) {
            $params['http']['header'] = $this->_headers;
        }

        return stream_context_create($params);
    }

    private function _openStream()
    {
        $this->_stream = @fopen($this->_url, 'rb', false, $this->_assemble());

        if (!$this->_stream) {
            throw new Exception('It was not possible to '
                              . "connect to {$this->_url}.");
        }
    }
}

More on this in my next post.