2. What is it?
CI is a HMVC framework for rapid PHP web application
development.
It’s focused on performance, ease of use and minimal
configuration.
MVC pattern is encouraged but not enforced.
3. What is it?
It has been mantained by EllisLab until 2014 ( http:
//ellislab.com/ ) . Since then the code is mantained by
British Columbia Institute of Technology ( http://bcit.ca/ )
Find the contributors list on the GitHub project page:
https://github.com/bcit-
ci/CodeIgniter/graphs/contributors
4. Why using it
● Flexible and easy to extend
● Lightweight and performant
● Noob friendly
● Minimal configuration
● It can use templating engines, but doesn’t need one
● VERY well documented
● CI Sparks / Composer
● Active community
5. Main features
● HMVC architecture
● Query-builder database support
● Drivers for main DBMS systems (MySQL,
MS SQL Server, Postgres, Oracle etc...)
● CSRF and XSS Filtering
● Session management
● Benchmarking
6. Main features
● Image manipulation (requires GD, ImageMagick
or NetPBM)
● Email library
● Uploading
● Caching
● CLI interface
● Internationalization
● … too many to be listed here.
7. Architectural goals
● Dynamic instantiation: libraries and helpers are loaded
by controllers on demand when they are needed, keeping
the system light and reactive
● Components singularity: each class and its functions are
highly autonomous in order to allow maximum usefulness
● Loose coupling: each component minimizes its reliance
on other components, becoming more reusable.
8. Requirements
● PHP 5.2.4 (5.4 is recommended)
● A Web Server
Remind that, as of PHP 5.4, the interpreter
provides a built-in web server to test your
applications. So you do not really need a stand
alone web server to start developing.
9. application/config/config.php holds most of the
configuration you need to start developing your
application, such as base_url (e.g. http://google.
com/, if Google was written with CI), URLs suffixes,
default charsets, locales, hooks configuration,
Composer integration and much more.
Basic configuration
10. Routing & Controllers
Preliminar note: CI provides a index.php script which triggers the
framework lifecycle for each request.
To remove index.php from URL and to route every request to it, you can
use mod_rewrite on Apache like this https://gist.github.
com/sixpounder/c61e660b43c0aa2b9356
For PHP builtin server look at this GIST https://gist.github.
com/sixpounder/6758cddd83330125bc10
From now on we assume index.php to be removed from URLs.
12. Routing & Controllers
CI URLs are basically query string arguments to
index.php. They are made of URI segments that
represent (by default, but this can be changed in
application/config/config.php by defining custom
routes) the controller and the method
responsible for serving a request mapped on
that specific URL.
13. Routing & Controllers
example.com/news/article/ID
● The first segment represents the controller class to be
invoked
● The second segment represents the controller instance
method that will be executed (assuming index if not
specified)
● The third (and any further) segment represents an
additional parameter that will be passed to the
controller method as an argument.
14. Routing & Controllers
● These URLs are SEO-friendly!
● You can organize controllers in sub folders. In this case,
the initial URI segments will represent your folder
structure.
● Classic query strings are available
● You can add URLs suffixes
● You can define overrides, custom URI routings and the
default controller in application/config/routes.php
15. Routing & Controllers
Controller classes extend CI_Controller and must be
placed in application/controllers. Class name must have
its first letter capitalized and it must match the file
name.
/* application/controllers/Article.php */
class Article extends CI_Controller { … }
16. Models are classes that interacts with your
database. CI doesn’t provide an ORM like
Rails Active Record, rather it provides a
Query Builder that builds queries by
masking the underlying physical DBMS
implementation.
Models
17. Models
● Models should be indepent from the components
that use them
● Query Builder supports transactions
● Database Forge Class can be used to manage the
physical structure of your database (so you do not
have the responsability to do so!)
● Support for migrations (by extending CI_Migration)
18. Models
To load and use a model inside a controller:
$this->load->model(‘model_name’);
Models must be placed in application/models. Classes
and file names must have their first letter capitalized
and the rest of the name lowercase. They must extend
CI_Model.
19. Views & Templating
CI’s core provides different ways of sending
an output to a client, like basic view
rendering, simple template parsing and
direct output control. All these methods are
wrapped into core libraries.
20. Views & Templating
View rendering
A view is simply a web page, or a page fragment, like a header, footer,
sidebar, etc. In fact, views can flexibly be embedded within other views
(within other views, etc., etc.) if you need this type of hierarchy.
Views are stored by default in application/views directory and have .php
extension (unless you need something different, eg. if you are using twig).
A controller can render a view by loading it like this:
$this->load->view(‘viewname’);
21. Views & Templating
View rendering
Data is passed from the controller to the view by way of
an array or an object in the second parameter of the
view loading method.
$data = array('title' => 'My Title','heading' => 'My Heading','message' => 'My
Message');
$this->load->view('blogview', $data);
22. Views & Templating
View rendering
A third boolean argument may be provided to the view
loader. If it is present and its value is TRUE the method
returns the string representation of the finalized view.
This can be usefull for templating purposes.
$data = array('title' => 'My Title','heading' => 'My Heading','body' => 'Article
body');
var $content = $this->load->view('article', $data, TRUE);
23. Views & Templating
Output Library
The Output Library is used under-the-hood by the view
loader to finalize the output before sending it to the
client. It can be directly used, for instance, to send a
JSON output if you are dealing with a REST API, or a file’s
content if you are writing a file server and so on.
24. Views & Templating
JSON example
$this->output->set_content_type('application/json')->set_output(json_encode(array
('foo' => 'bar')));
Sending an image
$this->output->set_content_type('jpeg')->set_output(file_get_contents
('files/something.jpg'));
HINT: The _display() method is called automatically at the end of script execution, you won’t need
to call it manually unless you are aborting script execution using exit() or die() in your code.
Calling it without aborting script execution will result in duplicate output.
25. Views & Templating
Template Parser
The Template Parser Library can parse simple templates
by operating basic substitutions of pseudo-variables
contained in your views.
Pseudo variables must be enclosed in braces.
26. Views & Templating
Template Parser
$this->load->library('parser');
$data = array(
'blog_title' => 'Six Blog',
'blog_heading' => 'A blog about computing',
'blog_entries' => array(
array('title' => 'Title 1', 'body' => 'Body 1'),
array('title' => 'Title 2', 'body' => 'Body 2'),
array('title' => 'Title 3', 'body' => 'Body 3'),
array('title' => 'Title 4', 'body' => 'Body 4'),
array('title' => 'Title 5', 'body' => 'Body 5')
)
); // This could be the result of a query as well!
$this->parser->parse(tpl', $data);
28. Libraries & Helpers
CI provides a bunch of libraries and helpers.
We already saw the Output library (one of
the few libraries that are auto loaded by CI
itself), but there are many more.
29. Libraries & Helpers
Benchmarking Class
Caching Driver
Calendaring Class
Shopping Cart Class
Config Class
Email Class
Encrypt Class
Encryption Library
File Uploading Class
Form Validation
FTP Class
Image Manipulation Class
Input Class
Javascript Class
Language Class
Loader Class
Migrations Class
Output Class
Pagination Class
Template Parser Class
Security Class
Session Library
HTML Table Class
Trackback Class
Typography Class
Unit Testing Class
URI Class
User Agent Class
XML-RPC and XML-RPC Server Classes
Zip Encoding Class
30. Libraries & Helpers
Helpers, as the name suggests, help you with tasks. Each
helper file is simply a collection of functions in a particular
category.
There are URL Helpers, that assist in creating links, there are
Form Helpers that help you create form elements, Text
Helpers perform various text formatting routines, Cookie
Helpers set and read cookies, File Helpers help you deal with
files, etc
31. Libraries & Helpers
Array Helper
CAPTCHA Helper
Cookie Helper
Date Helper
Directory Helper
Download Helper
Email Helper
File Helper
Form Helper
HTML Helper
Inflector Helper
Language Helper
Number Helper
Path Helper
Security Helper
Smiley Helper
String Helper
Text Helper
Typography Helper
URL Helper
XML Helper
32. Extending CodeIgniter
CI provides many ways to extend the framework
● Custom libraries
● Estensione system libraries
● Hooks
● Sparks plugins ( http://getsparks.org/ )
● Easy integration with Composer
33. Extending CodeIgniter
You can replace or extend the system libraries provided by CI.
To replace them with your own implementation,simply create a
library with the same name as the one you want to replace in
application/libraries.
To extend them, create a new class prefixed by the default extender
prefix (see application/config/config.php), like this:
class MY_Email extends CI_Email { … }
35. Extending CodeIgniter
Defining a hook
in application/config/hooks.php each key in $hook represents a script at a certain point of the
application lifecycle:
$hook['pre_controller'] = array(
'class' => 'MyClass',
'function' => 'Myfunction',
'filename' => 'Myclass.php',
'filepath' => 'hooks',
'params' => array('beer', 'wine', 'snacks')
);
Available hook points are: pre_system, pre_controller, post_controller_constructor,
post_controller, display_override, cache_override, post_system.