This chapter covers the CI libraries topic, and the different types of libraries and their different usage categories, with several code examples of web applications. The CI development platform provides us with the built-in libraries, enables us with an easy procedure to integrate third-party libraries, and also allows us to develop our new libraries and share them with the community, if we wish to.
The CI libraries are powering efficiency, code reusability, separation, and simplicity. The benefits achieved are as follows:
- Efficiency: In means of minimal loaded resources. This feature achieved by the fact that the CI library, may be loaded only by the specific CI project controller(s), or even only in specific method(s), where the library's services are required. Hence, the overhead (memory) of the library resources during execution time is minimized in each controller operation state.
- Reusability: Reusability means writing once a function code and reusing it across the project resources. The libraries can be loaded by any project controller, model, or helper (in a helper, we shall use the
&get_instance()method discussed several times before) to reuse their code anywhere in the CI project. More than that, the controller-rendered views can call those loaded library methods. Hence, great code reusability is achieved. - Separation: Separation prevents, accidental overlapping with same name to the parameters or functions elsewhere in the project. The Library class methods and parameters have their own name space so that they can't be overridden by a mistake outside the library in case the developer is using the same parameters in the served module such as controllers/views.
- Simplicity: This make the code text as minimal as possible and easy to understand and maintain. The libraries' methods called from the served resources, such as controllers, models, and helpers, make the code look much simpler, and make it easy to maintain and navigate. Hence, this simplifies extending the code and maintaining it.
The libraries give us development power and efficiency with rich-focused functionality on certain project aspects, and also enable us to have simple and concise fashion code in the served controllers by calling the library method, instead of having the service code locally in the controller. The libraries should be initially instantiated by the code using them, such as the controller, model, or helper, or if used by almost all controllers, models can be loaded using the autoload mechanism. Chapter 2, Configurations and Naming Conventions, discusses how to autoload the libraries.
Once instantiated by the autoload or controller constructor, the libraries can be used by the controller methods or by rendered views. In addition, any model, helper, or another library may use our project installed libraries using &get_instance(), as described in the previous chapters.
The libraries power the code of the CI model-view-controller instantiated components (for more information, visit the website http://en.wikipedia.org/wiki/Model-view-controller), regarding the functionality expansion and reusability across the project controllers, models, helpers, and views.
This chapter will primarily focus on the following topics:
- The CI libraries' scope and usage:
- Usage categories
- Using a library
- Adding a library to the project
- Instantiating a library
- Using library method(s)
- Available CI libraries
- Examples:
- Example 1: using the built-in libraries
- Example 2: using third-party libraries such as the Google Maps CI library wrapper
- Example 3: building our own library such as the Flickr API wrapper
- Example 4: building our own library such as the LinkedIn API wrapper
We will begin by briefly reviewing what a library in a CI framework is, and how we can use it for our needs across the project code resources.
The CI library does not have access to the controller resources by default unless the CI $ci = &get_instance() is called and $ci is used instead of $this to access the CI resources, for example, instead of $this->db->query ($sql), we shall use $ci->db->query ($sql), and so on. We can extend the CI library using the third-party libraries from where CI echo system (the CI community of developers worldwide share knowledge, sources, and solutions for code and open issues), or develop our own libraries from scratch or extending other libraries.
Any application library will be located under application/libraries/ in the project's directory. In addition, optional resources such as the library configuration file that is required for library configurations can be placed under the project root or elsewhere. A good practice is to place them under the project root for enhanced security provided by CI. For example, <PROJECT_ROOT>application/config/<LIB_NAME>_config.php, or even additional resources such as the images/CSS/HTML/additional class libraries may be required under another application/<LIB_ADDITIONAL_RESOURCES>, such as application/assets.
The library integration and the usage within the CI project are as follows:
- Adding the library code resources to
application/libraries/my_lib.php, optionally adding related resources, if any, such as a library configuration file, and/or other library assets to their locations as mentioned before. - Instantiating the library class via config autoload, or instantiating it via the controller.
- Automatically load a library
my_libfor the entire CI project:$autoload['libraries'] = array('database','my_lib'), - Specifically in certain controller(s), constructor(s), or method(s):
$this->load->library('my_lib'),
- Automatically load a library
- Using the library methods:
$result=$this->my_lib->called_method ($param1, $param2);
- We can see the library scope as the ultimate OOP reusability enabler for the entire project code resources' models, views, helpers, and libraries, which govern all to address the execution requests from the user, or a scheduled request.
As mentioned, the CI libraries enables us with great Separation and Simplicity. For example, the following code:
// Library class
class my_handler {
private $my_lib_param;
// Can't be accessed outside the class directly
// but we can provide the read only service as follows:
public function get_my_lib_param () {
return $this->my_lib_param;}
// The following is a library function that can't
// be called from outside the class!
private function my_private_function () { }
}CI and the CI echo system of developers provide many libraries covering a rich set of topics. We will review the CI libraries as well as known resources for the third-party CI libraries.
We are also encouraged to build our own libraries that can be used by others, and share them with the community, such as:
- The Git community at https://github.com
- CI Sparks at http://getsparks.org
- CI Forums at http://codeigniter.com/forums
- Packagist at https://packagist.org
To call a built-in library, we shall call for example, the built-in library named CI_Xxxx as follows: $this->load->library (xxxx);. So that CI_ prefix is not used and instead of the capitalized library name Xxxx, we use the lowercase library name xxxx. For calling a library function yyyy within the library CI_Xxxx, we shall write $this->xxxx->yyyy();.
The following is a list of built-in and commonly useful CI libraries (As of version 2.1.4):
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
|
In this chapter, we will provide a usage example for Google Maps' third-party library wrapper, available at https://github.com/ianckc/CodeIgniter-Google-Maps-Library.
Many more third-party libraries can be found following the CI forums at http://codeigniter.com/forums.