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…
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…
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…
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…
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…
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.
When it comes to choosing a Linux web server, Apache, as we all know, is almost a de facto standard. There is even a chance that your web host does not even offer (or worse, know of) an alternative web server. So, it’s not a big surprise that many developers don’t know too much about what other alternatives are available to them.
Recently, a client of mine wanted a single web form, residing on the localhost to submit the form contents to a database in the localhost, and as well as to a web server simultaneously. Although this sounds like an unnecessary duplication of data, my client wanted some of the form data to be stored on the localhost for the intranet applications to use. Achieving this functionality would have been a piece of cake, if we were not handicapped by the unavailability of cross-domain AJAX. For those of us familiar with AJAX, we know that we cannot send an AJAX request to a remote server due to security reasons – atleast not in a reliable, hack-less way.
So, instead of looking for a pure AJAX solution, I decided to implement this functionality by using a combination of AJAX (for the localhost) and a traditional PHP POST request (for the web server). The trick here is to execute the AJAX call before the form is submitted – by catching the form submission event using JavaScript. Once the AJAX call is successful, we allow the default form submission to take place. In case there is an error with our AJAX call, we should…
Subscribe to feeds
