• Partie 1 - Introduction

1. La notion de framework
2. Présentation de l'architecture MVC
3. Installation et configuration
• Partie 2 - Mise en place des cinq composants
1. Le contrôleur
2. La vue
3. Les helpers
4. Les bibliothèques
5. Le modèle
• Partie 3 - Utilisations avancées
1. L'outil Profiler
2. Modification de la classe Model : le CRUD
3. Mise en place des thèmes
La notion de framework
Dans ce chapitre, nous allons définir ce qu'est un framework. Ensuite, nous nous attarderons sur les possibilités de
CodeIgniter.
Chaque framework possède des avantages et des inconvénients. À vous de faire votre choix parmi la multitude de
frameworks PHP déjà présents sur le net.

Le framework CodeIgniter
Présentation
Le CodeIgniter a été conçu dans le but de ne fournir que le strict minimum. Tout le reste est entièrement optionnel
(même les bibliothèques gérant les bases de données et les sessions le sont).
Cela lui permet donc d'être doublement rapide. Le temps de génération de votre page, CodeIgniter se retrouve souvent en
très bonne position.
Libraries et Helpers
Le socle initial permet aux codeurs d'inclure des bibliothèques et des fonctions fournies par CodeIgniter. Elles sont
nombreuses.
La colonne Class Reference regroupe des classes que vous pourrez utiliser lorsque vous en aurez besoin. Vous y
trouverez notamment les plus importantes :
• config pour récupérer toute votre configuration. Vous allez pouvoir personnaliser votre framework ;
• database pour les bases de données. Nous la découvrirons, car elle est assez conséquente ;
• form_validation pour simplifier la vérification des formulaires. Une fois que l'on y touche, on ne peut plus s'en
passer ;
• session pour les sessions. CodeIgniter n'utilise pas les sessions natives mais son propre système.
Par la suite nous verrons une fraction des bibliothèques, mais il est possible de créer ses propres classes et même de
modifier le comportement de celles fournies par CodeIgniter.
Les helpers sont tout simplement des ensembles de fonctions regroupées par thème. Ici encore, nous allons pouvoir créer
nos propres helpers et même redéfinir les fonctions de CodeIgniter lorsqu'elles ne nous plairont pas. Nous avons donc des
fonctions pour générer nos URL, générer nos formulaires, insérer des smileys ou encore utiliser un catpcha.
En résumé
Le CodeIgniter est une base réduite en fonctionnalités mais hautement performante, pouvant faire appel à des classes et à
des fonctions très complètes lorsque le besoin s'en fait sentir.
Maintenant, nous allons pouvoir nous intéresser à l'organisation de nos fichiers avec l'architecture MVC.
Installation et configuration
Téléchargement et installation
Téléchargement
Rendez-vous sur le site officiel de CodeIgniter pour pouvoir télécharger le framework,
Une fois qu'elle sera téléchargée, il faudra décompresser l'archive et placer le dossier portant le même nom que la version
dans votre répertoire web. Vous pouvez le placer où vous voulez. Pour les besoins, nous allons renommer le dossier en
codeIgniter et le placé dans le répertoire www.
Installation
Quelques modifications
Dans votre dossier codeIgniter, vous avez normalement deux fichiers : index.php et licence.txt. Vous pouvez faire ce que
bon vous semble de la licence.
Ensuite, vous avez la documentation dans le dossier user_guid. Vous pouvez aussi en faire ce que bon vous semble.

index.php
Maintenant, vous allez ouvrir le fichier index.php. La première chose à configurer est de définir si le framework est
actuellement en période de développement, de test ou de production. La conséquence immédiate est l'affichage ou non
des erreurs. Normalement, la constante est déjà sur development.
<?php
define('ENVIRONMENT', 'development'); // (development | testing | production)
Une fois cela fait, vous pouvez modifier les deux variables suivantes : system_path et application_folder. Le premier est
le chemin vers le dossier system et le second est celui vers le dossier application.
La configuration par défaut est fonctionnelle. On pourra par la suite les changer sans problème.
<?php
/*
|---------------------------------------------------------------
| SYSTEM FOLDER NAME
|---------------------------------------------------------------
*/
$system_path = "system";
/*
|---------------------------------------------------------------
| APPLICATION FOLDER NAME
|---------------------------------------------------------------
*/
$application_folder = "application";
La documentation de CodeIgniter recommande de renommer ces dossiers pour éviter à un visiteur mal intentionné de
connaître leur emplacement. Vous pouvez vous en passer dans un premier temps.
Vous avez fini d'installer CodeIgniter. Vous avez normalement accès à la page d'accueil du framework (c'est
http://localhost/codeIgniter/) et celui-ci vous souhaite la bienvenue.
Si vous ne voyez pas ce message, reprenez bien les étapes dans l'ordre et assurez-vous de bien avoir les prérequis de votre
version téléchargée (version minimale de PHP, droits de lecture...).
Mise en place de l'arborescence
Maintenant que le framework est installé, regardons sur l'arborescence de CodeIgniter.
Les dossiers application et system
À côté de votre index.php, vous avez deux dossiers : application et system. Le dossier system contient tous les codes
natifs de CodeIgniter alors que le dossier application va contenir tous vos codes. Vous ne devrez donc jamais modifier
les fichiers présents dans le dossier system, et on va vous en expliquer la raison tout de suite.
Imaginons que vous n'aimez pas le nom d'une méthode. Vous allez donc lancer une petite recherche et modifier le nom de
cette méthode. Sauf que vous allez avoir de gros problèmes maintenant. En voici trois qui méritent d'être cités.
• Si une nouvelle version de CodeIgniter sort, vous allez devoir refaire vos manipulations. Et ne dites pas que vous
ne ferez pas la mise à jour, car vous risquez des problèmes de sécurité.
• En modifiant les sources, vous êtes susceptibles de laisser passer des failles, car il y a de fortes chances que vous
ne connaissiez que l'aspect « utilisateur » du framework.
• Un des avantages de l'utilisation d'un framework est la facilité de travailler à plusieurs, car chacun sait comment
le système fonctionne. Mais si vous modifiez les sources de CodeIgniter, son comportement ne sera plus le
même.
Nous verrons par la suite comment effectuer ces changements sans toucher à ce dossier.
Le dossier assets
Avant de décrire précisément le contenu du dossier application, vous allez créer un dossier assets, toujours dans le même
dossier que le fichier index.php. Et à l'intérieur de celui-ci, créez aussi les dossiers css, javascript et images.
Vous disposez maintenant d'une arborescence très claire.
• assets contiendra toutes les ressources qui vont être téléchargées par les visiteurs. Par exemple, les feuilles de
style externes (CSS), les fichiers JavaScript et les images. Cependant, vous pouvez aussi ajouter des dossiers tels
que musiques, videos, xml (pour les flux RSS, les animations flash). C'est comme si vous alliez faire un copier-
coller de ce dossier dans l'ordinateur de vos visiteurs. Rien ne doit être confidentiel.
• system contient les sources de CodeIgniter, vous ne devez pas y toucher.
 • application contiendra tous vos scripts, qu'il faudra placer dans les bons dossiers. C'est ce que nous allons voir
tout de suite.
Le dossier application
Voici l'arborescence du dossier application avec les explications des dossiers dont nous nous servirons dans la prochaine
partie.

• config : ce sont des fichiers permettant de configurer CodeIgniter ou une bibliothèque. Certains sont inclus
automatiquement, d'autres seulement lorsque vous les demandez.
• controllers : ce dossier contiendra tous nos contrôleurs.
• errors : ce sont les pages d'erreurs. Libre à vous de les personnaliser selon votre design.
• helpers : c'est le répertoire pour vos helpers. Les helpers fournis avec CodeIgniter sont situés dans le dossier
system.
• hooks : c'est un dossier qui contient des fichiers assez complexes. Ils permettent d'exécuter des scripts à différents
moments du processus d'exécution de CodeIgniter.
• language : ce répertoire contiendra tous vos fichiers de langue dans le cas où vous souhaitez un site
internationalisé.
• libraries : nous placerons nos bibliothèques dans ce dossier. Comme les helpers, les bibliothèques fournies par
CodeIgniter sont situées dans un autre dossier.
• models : le répertoire des modèles.
• views : le répertoire des vues.
En respectant les emplacements des différents fichiers, vous gagnerez en clarté.
Configurons CodeIgniter
Certes, l'installation est terminée, mais il reste encore certains points à définir.
Le fichier config.php
Ce fichier de configuration est le cœur de la configuration du framework. Il se trouve dans le dossier ./application/config/.
On va pas décrire tous les points mais sachez que nous allons aborder les plus importants.
base_url
C'est l'URL que vous devez taper pour accéder au fichier index.php. Dans notre cas, ce sera :
<?php
/*
|--------------------------------------------------------------------------
| Base Site URL
|--------------------------------------------------------------------------
*/
$config['base_url'] = "http://localhost/codeIgniter/";
index_page
Par défaut, la valeur est index.php. Nous allons voir que CodeIgniter génère par défaut des URL de cette forme-là :
http://localhost/codeIgniter/index.php/classe_controleur/methode_controleur/.
Problème, ce « index.php » n'est pas des plus jolis. Pour le masquer, il y a une solution : l'URL rewriting. Si vous avez
activé ce module, alors vous pouvez créer un fichier .htaccess à côté du index.php contenant ce code :
# Empêche la visualisation de l'arborescence, n'a rien à voir avec le masquage du « index.php ».
Options -Indexes
# Active le module de réécriture d'URL.
RewriteEngine on
#
# Fixe les règles de réécriture d'URL. Ici, nous utilisons une liste blanche.
#
# Toutes les URL qui ne correspondent pas à ces masques sont réécrites.
RewriteCond $1 !^(index\.php|assets/|robots\.txt)
# Toutes les autres URL vont être redirigées vers le fichier index.php.
RewriteRule ^(.*)$ index.php/$1 [L]
Une fois cela fait, vous pouvez vider la variable index_page puisque les URL seront redirigées vers ce fameux fichier
index.php.
<?php
/*
|--------------------------------------------------------------------------
| Index File
|--------------------------------------------------------------------------
*/
// Dans le cas où mod_rewrite est activé
$config['index_page'] = "";
// Dans le cas contraire
$config['index_page'] = "index.php";
Maintenant, vos URL ne contiendront plus le « index.php ».
url_suffix
C'est le suffixe que vous voulez donner à vos URL. Vous pouvez donner n'importe quoi. CodeIgniter l'ignorera...
Dans notrecas, nous allons choisir l'extension html. Vous pourrez tout aussi bien ne rien mettre. C'est facultatif.
<?php
/*
|--------------------------------------------------------------------------
| URL suffix
|--------------------------------------------------------------------------
*/
$config['url_suffix'] = ".html";
language
Cette option permet de configurer la langue par défaut. C'est très utile si vous voulez afficher les erreurs en français et
non en anglais.
Cette langue sera aussi utilisée pour les messages d'erreurs lorsque vos formulaires ne seront pas bien remplis. Si vous
voulez faire un site en français, prenez le temps de faire cette manipulation.
Si c'est le cas, alors il va falloir modifier certaines choses. Dans un premier temps, passez cette variable à « french ».
<?php
/*
|--------------------------------------------------------------------------
| Default Language
|--------------------------------------------------------------------------
*/
$config['language'] = "french";
Désormais, lorsqu'il y aura une erreur, CodeIgniter voudra l'afficher en français. Sauf que CodeIgniter ne propose qu'un
jeu de langue anglais... Jetez un petit coup d'œil aux fichiers situés dans le répertoire ./system/language/. Il n'y a que le
dossier english.
Vous avez donc deux solutions : traduire l'ensemble des fichiers de langue ou récupérer un fichier de langue sur le web.
Si vous voulez récupérer un fichier de langue, vous pourrez en trouver sur le wiki officiel ou bien dans les sources de
PyroCMS. C'est un CMS qui a été développé avec CodeIgniter. Il vous suffit de télécharger ce CMS, de le décompresser
et d'aller dans le répertoire ./codeigniter/language/. Dans ce dossier, vous avez accès à une panoplie de langages, dont le
français (french). Il vous suffit donc de déplacer le dossier french de PyroCMS jusque dans votre répertoire
./system/language/.
Maintenant, CodeIgniter est en mesure d'afficher les erreurs en français.
session
Vous pouvez aussi configurer l'utilisation des sessions.
Voici ce que vous pouvez paramétrer :
<?php
// Le nom du cookie...
$config['sess_cookie_name'] = 'ci_session';
// La date de péremption du cookie, en secondes...
$config['sess_expiration'] = 7200;
En plus de cela, CodeIgniter propose de stocker les sessions dans votre base de données au lieu de les stocker dans les
cookies.
Si vous stockez souvent beaucoup de données dans les sessions, choisissez évidemment la base de données. Dans la
plupart des cas, on vous conseille de prendre cette option car elle offre en plus une sécurité identique aux sessions natives
de PHP.
Si vous êtes intéressés par cette fonctionnalité, alors vous devez dans un premier temps créer une table ci_sessions dans
votre base de données.
Ce code vous permettra de générer la table. Il s'agit d'un simple code SQL.
CREATE TABLE IF NOT EXISTS `ci_sessions` (
session_id varchar(40) DEFAULT '0' NOT NULL,
ip_address varchar(16) DEFAULT '0' NOT NULL,
user_agent varchar(120) NOT NULL,
last_activity int(10) unsigned DEFAULT 0 NOT NULL,
user_data text NOT NULL,
PRIMARY KEY (session_id),
KEY `last_activity_idx` (`last_activity`)
);
Une fois ceci fait, vous devez lui dire d'utiliser la base de données.
<?php
// La valeur TRUE permet d'utiliser la base de données
$config['sess_use_database'] = TRUE;
// Le nom de la table
$config['sess_table_name'] = 'ci_sessions';
compress_output
Cette clé permet d'activer la compression Gzip. Elle est désactivée par défaut car tous les hébergeurs ne supportent pas
cette fonctionnalité. Pour rappel, cette compression permet de réduire la taille du contenu envoyé au navigateur. En
théorie, les pages devraient se charger plus rapidement.
Lorsque que vous êtes en développement, désactivez cette fonctionnalité car si vous ne respectez pas les standards du
MVC, votre page ne s'affichera pas. Il est courant d'utiliser la fonction var_dump un peu n'importe où. Cependant, si vous
affichez des données à l'extérieur des vues, l'affichage de votre page plantera.
Maintenant que cela est fait, nous allons configurer notre base de données.
Le fichier database.php
Dans ce fichier, vous noterez vos identifiants et le mot de passe de connexion à votre base de données.
<?php
/*
| -------------------------------------------------------------------
| DATABASE CONNECTIVITY SETTINGS
| -------------------------------------------------------------------
*/
$db['default']['hostname'] = "nom_d_hote";
$db['default']['username'] = "nom_d_utilisateur";
$db['default']['password'] = "mot_de_passe";
$db['default']['database'] = "base_de_donnees";
Maintenant, votre base de données est opérationnelle.
Vous avez la possibilité d'inscrire plusieurs bases de données. En effet, la base de données d'exemple utilise la ligne
« default ». Vous pouvez ajouter d'autres lignes dans le tableau $db pour gérer tous vos identifiants.
Le fichier autoload.php
Ce fichier vous permet d'inclure dès le lancement de CodeIgniter des bibliothèques, des helpers, ainsi que des modèles et
fichiers de langue.
Bibliothèque
Je vous propose de charger au démarrage du framework deux bibliothèques : les sessions et les bases de données. Je
trouve que ce sont des fonctionnalités « élémentaires » qui nécessitent d'être constamment utilisées ou presque.
Pour faire cela, vous devez ajouter dans le tableau les bibliothèques que vous voulez charger.
<?php
/*
| -------------------------------------------------------------------
| Auto-load Libraries
| -------------------------------------------------------------------
*/
$autoload['libraries'] = array('database', 'session');
Lorsque vous connaîtrez plus de bibliothèques, ou que vous aurez besoin d'inclure les vôtres, vous pourrez les ajouter à la
suite.
Helpers
Nous allons aussi charger un helper : url. Il nous permettra d'écrire des URL en fonction des paramètres que vous aurez
définis dans le fichier ./application/config/config.php. En utilisant ces fonctions, toutes vos URL seront instantanément
modifiées si la valeur de $config['base_url'] est modifiée.
<?php
/*
| -------------------------------------------------------------------
| Auto-load Helper Files
| -------------------------------------------------------------------
*/
$autoload['helper'] = array('url');
Nous en avons fini avec la configuration de CodeIgniter.
Cette partie est terminée. Nous allons maintenant attaquer la deuxième partie.
Comme on vous l’a dit dans la partie précédente, c'est le contrôleur qui est appelé en premier. Nous allons donc aborder
celui-ci dès maintenant.

Présentation de l'architecture MVC Le contrôleur

Présentation de l'architecture MVC
Si vous développez en PHP depuis un certain temps, vous avez sûrement dû entendre parler de l'architecture MVC.
Le MVC n'est pas spécialement compliqué, il suffit d'être méthodique.
Découverte de l'architecture MVC
MVC est l'acronyme de Modèle-Vue-Contrôleur ! Autrement dit, nous allons séparer notre application en au moins trois
parties.

Pourquoi ?
Eh bien parce que cela va nous permettre de mieux nous organiser !
Il est vrai qu'au début, vous n'en verrez pas tout de suite l'intérêt. Mais lorsque votre site web commencera à prendre de
l'ampleur, vous devrez par exemple changer de design, changer le SGBD de votre base de données ou encore ajouter un
groupe VIP. Toutes ces modifications annoncent de très lourds changements si vous ne savez exactement où se situe le
code à modifier.
Nous allons justement aborder une organisation robuste composée de trois couches d'abstraction.
Le contrôleur
Le contrôleur est ce qui va être appelé en premier. Il n'y a qu'un seul contrôleur par URL. Donc, deux URL différentes
appelleront deux contrôleurs différents.
Le contrôleur se charge d'appeler tous les composants : bibliothèques, helpers, vues, modèles, mais aussi de faire les
nombreuses vérifications nécessaires.
Voici quelques exemples de fonctionnalités que peut fournir un contrôleur.
• Vérifier si le formulaire a bien été rempli.
• Vérifier si le visiteur a bien le niveau requis pour voir la page (administrateur par exemple).
• Changer le design selon les préférences du visiteur (via un cookie, par exemple).
• Contrôler les tokens (ou jetons) de sécurité. Si vous ne connaissez pas ces petites bêtes, ce n'est pas grave (tout
du moins pour ce tutoriel).
Le contrôleur sera donc la partie la plus importante pour le développeur PHP. Tout ce qui se passe dans le contrôleur sera
invisible aux yeux des visiteurs. Le contrôleur n'a pas pour rôle d'envoyer au navigateur un message d'erreur, il a pour
rôle de trouver cette erreur. L'affichage de cette erreur se fera via une autre couche d'abstraction.
Avec CodeIgniter, vous verrez que chaque contrôleur est une classe qui est appelée selon l'URL. Et comme toute classe
qui se respecte, elle possède un certain nombre de méthodes qui représenteront les différentes actions que le contrôleur
peut effectuer.
Par exemple, si on a cette URL : http://nomdedomaine.tld/news/voir_news.html, cela signifie que CodeIgniter doit
appeler dans la classe News la méthode voir_news. C'est donc l'URL qui appelle le contrôleur.
Les vues
Les vues sont directement responsables de tout ce que l'on va envoyer aux navigateurs. Les vues seront donc
composées principalement de HTML. Nous y trouverons aussi du PHP qui nous servira pour afficher des variables et faire
quelques boucles.
Il n'y a pas de limite au nombre de vues. Alors qu'avec les contrôleurs, nous avions une URL par contrôleur, ici, nous
pouvons très bien avoir cinq vues par contrôleur. Le rôle du contrôleur est aussi d'appeler la bonne vue. De plus, rien
n'empêche le contrôleur de faire appel à plusieurs vues.
Cette relation est représentée sur le schéma par un trait plein allant du contrôleur à la vue.
Sur ce même schéma, vous pouvez voir un trait en pointillé : il s'agit d'un flux indirect. Il est possible, au lieu d'afficher la
vue au moment où le contrôleur l'appelle, de sauvegarder son contenu dans une variable, en vue de le stocker dans un
fichier par exemple. Ce n'est utile que dans certains cas très particuliers.
Par exemple, pour la page d'accueil de l'administration d'un site, nous pourrons trouver ce genre de vues :
• une vue contenant le formulaire de connexion à la zone administrateur ;
• une vue contenant un message d'erreur ;
• une vue contenant la page d'administration.
Le rôle de la vue s'arrête là. C'est au contrôleur de savoir quelle est la vue qu'il doit charger.
Les modèles
Cette dernière couche d'abstraction permet de faire le lien entre le contrôleur et la base de données. Il est toujours
conseillé de séparer convenablement les requêtes que vous envoyez à la base de données et les instructions qui vont
utiliser ces données.
Le modèle permettra donc d'envoyer des requêtes à la base de données et d'en retourner le résultat sous forme brute (sans
HTML). Nous y trouverons donc des fonctionnalités typiques des bases de données (ajouter, modifier, supprimer...).
Dans la plupart des cas, si les bases de données ont bien été pensées, il y aura un modèle pour chaque table.
Prenons l'exemple d'une table sauvegardant des news. Le modèle associé à cette table devra être composé de ces
fonctionnalités :
• ajouter ;
• modifier ;
• supprimer ;
• nombre_news ;
• liste_news ;
• news.
Eh bien, pour réaliser cela avec CodeIgniter, vous allez devoir créer une classe que nous appellerons News_model, et
nous implémenterons toutes les méthodes dont nous aurons besoin pour manipuler les news dans la base de données. Il
nous suffira alors d'exécuter les méthodes de ce modèle depuis le contrôleur.
Pour en finir avec les modèles, il faut que vous sachiez qu'il est facultatif. Vous avez la possibilité de n'en inclure aucun.
Ce n'est pas obligatoire de charger un modèle dans le cas où vous ne souhaitez pas exécuter de requêtes avec votre base
de données. Mais nous aurons l'occasion d'en parler plus en détail par la suite.
Résumé
Le tableau
Dorénavant, quand vous développerez avec CodeIgniter, vous devez avoir le tableau suivant dans la tête.
 Nom de la
Rôle de la couche
couche
C'est le cœur de votre application. Ce sont eux qui seront appelés en premier. Ils seront l'intermédiaire
Contrôleurs
entre les modèles, les vues et toute autre forme de ressources.
Vues Principalement composées de code HTML, elles permettent de renvoyer le code aux visiteurs.

Modèles Facultatifs, ils permettent d'envoyer des requêtes à la base de données.

La plupart sont facultatives. Ce sont des classes qui permettent de nous aider. La bibliothèque de
Bibliothèques
vérification des formulaires est un très bon exemple.
Helpers Ce ne sont que des fonctions classées par thème.
Le diagramme
Voici un schéma très bien fait extrait de la documentation. Il illustre le fonctionnement de CodeIgniter.

Ordre Nom Description

1 index.php Ce sera toujours le fichier index.php, situé à la racine du répertoire, qui sera appelé en premier.
C'est le routeur. C'est lui qui récupérera l'URL et la décomposera en actions. Il a pour rôle de
2 Routing trouver le contrôleur à appeler. Nous verrons dans la suite de ce tutoriel que nous pouvons
modifier son comportement.
Une fois que le routeur a fini son travail, le module de cache va regarder s'il existe des fichiers
3 Caching mis en cache pour cette action. Dans le cas d'une réponse positive, ces fichiers vont être
renvoyés au navigateur.
Cette partie va sécuriser toutes les données entrantes : cookies, variables get, post, etc. C'est la
4 Security
dernière étape avant le contrôleur.
Application
5 Ce sera ici que nous commencerons à développer.
Controller

Models Libraries Comme vous le voyez, le contrôleur fait appel à différents éléments qui vont leur renvoyer des
6
Helpers données.
7 View Les vues sont les fichiers qui contiennent le code HTML.
Si vous êtes attentifs, vous avez dû voir que on n'a pas du tout parlé des plugins. En effet, les plugins ont été supprimés
depuis CodeIgniter 2.0, mais l'image n'en reste pas moins très intéressante.
Et voilà, maintenant que vous connaissez le framework et ses grandes lignes, nous allons enfin pouvoir le télécharger et le
configurer.
Le contrôleur
Dans cette partie, nous allons créer notre première page avec CodeIgniter.
Pour rappel, le contrôleur est ce qui sera chargé en premier dans votre application. C'est lui qui fera les vérifications. Il
aura accès aux sessions et à toutes les données transitant entre le navigateur et le serveur : get, post, cookie, etc.
Votre première page
Premier contrôleur
Nous allons créer notre premier contrôleur, alors le voici :
<?php
class Forum extends CI_Controller
{
public function accueil()
{
echo 'Hello World!';
}
}
Dans CodeIgniter, un contrôleur est un fichier contenant uniquement une classe. Tout se passera donc dans cette classe.
Écrivez cette classe dans un fichier forum.php et placez celui-ci dans le dossier ./application/controllers/. Si vous vous
rendez à l'adresse http://localhost/codeIgniter/index.php/forum/accueil/, vous verrez la page « Hello World! »
Veillez à donner le bon chemin dans l'URL dans le cas où vous avez placé le framework dans un autre dossier que nous
avons crée (codeIgniter).
Normalement, vous ne devez jamais afficher du texte depuis le contrôleur. Cela marche souvent très bien, sauf que vous
ne respectez pas l'architecture MVC. Nous verrons dans le chapitre suivant comment créer des vues.
Explication des URL
L'URL par défaut
Les URL sont formées à partir des contrôleurs en suivant ce modèle :
http://www.nomdedomaine.tld/index.php/classe_controleur/methode_controleur/.
C'est le cas dans l'exemple ci-dessus. Notre classe s'appelle Forum et elle comporte une méthode accueil. Cela se traduit
donc par une URL contenant ces segments : http://www.nomdedomaine.tld/index.php/forum/accueil.
L'URL avec une extension
Si vous avez bien suivi le chapitre précédent, vous aviez la possibilité de donner une extension aux URL. Il s'agit de la clé
de configuration url_suffix du fichier ./application/config/config.php. Pour ma part, je l'avais initialisée avec l'extension
html.
Dans ce cas, mon URL deviendra : http://www.nomdedomaine.tld/index.php/forum/accueil.html.
L'URL sans le index.php
Dans le chapitre précédent, je vous ai dit que vous pouviez activer l'URL rewriting pour masquer l'appel au fichier
index.php. Si vous avez fait cela, votre URL sera alors : http://www.nomdedomaine.tld/forum/accueil.html.
Rassurez-vous, il existe des fonctions toutes prêtes pour construire nos URL !
En résumé
Un contrôleur est donc un fichier qui contient une unique classe et ce sera son nom qui s'affichera dans l'URL.
Pour que CodeIgniter puisse savoir où est situé le contrôleur à appeler, vous devez nommer votre fichier du même nom
que votre classe mais sans la majuscule. De plus, le nom de la classe doit toujours commencer par une majuscule.
Fonctionnalités du contrôleur
Créez d'autres pages
Vous avez la possibilité de créer d'autres méthodes qu'accueil.
Exemple avec ce contrôleur :
<?php
class Forum extends CI_Controller
{
public function accueil()
{
echo 'Hello World!';
}
public function bonjour()
{
echo 'Salut à tous !';
}
public function manger()
{
echo 'Bon appétit !';
}
}
Désormais, votre contrôleur possède plusieurs pages qui seront accessibles de la même manière :
• forum/bonjour.html
• forum/manger.html
Chaque méthode permet donc de faire apparaître une page. Si avant cela, vous n'aviez jamais utilisé de framework, ce doit
déjà être une petite révolution.
Les variables $_GET
Maintenant que vous avez créé vos pages et que vous connaissez les URL pour y accéder, vous voulez peut-être utiliser
les variables $_GET. On n'aurait pas pu faire plus simple !
<?php
class Forum extends CI_Controller
{
public function accueil()
{
echo 'Hello World!';
}
// Cette page accepte une variable $_GET facultative
public function bonjour($pseudo = '')
{
echo 'Salut à toi : ' . $pseudo;
 }
// Cette page accepte deux variables $_GET facultatives
public function manger($plat = '', $boisson = '')
{
echo 'Voici votre menu : <br />';
echo $plat . '<br />';
echo $boisson . '<br />';
echo 'Bon appétit !';
}
}
Ces URL seront tout à fait correctes :
forum/accueil/
forum/bonjour/Arthur.html
forum/manger/Hamburger-frites/coca.html
Alors, comment, la POO ?
Ainsi, votre site web se découpera en contrôleurs, qui auront chacun des méthodes. L'ensemble formera votre site. Voici
un exemple :
User Accueil Forum
accueil accueil accueil
inscription faq categorie
desinscription reglement voir_post
connexion plan voir_message

deconnexion contact
profil
Si vous aviez déjà pris l'habitude de « découper » votre site en modules (news, forum, livre d'or...), alors la migration vers
CodeIgniter sera rapide. En revanche, si vous aviez opté pour quelque chose d'un peu plus exotique, dites-vous qu'au
moins votre site sera dorénavant plus organisé.
Organisez vos contrôleurs dans des dossiers
Dans le cas où vous créez un gros projet qui nécessite de nombreux contrôleurs, CodeIgniter vous autorise à les placer
dans des dossiers. Cependant, vous vous doutez bien que ce n'est pas aussi simple que cela.
Si, par exemple, vous voulez placer 3 contrôleurs dans un dossier « forum », alors votre URL devra afficher le paramètre
« forum » en premier, avant le nom du contrôleur :
forum/contrôleur/méthode/
Un contrôleur orienté objet
N'oubliez pas que le contrôleur n'est pas uniquement un moyen de classer ses pages ! Il s'agit avant tout d'une classe.
Autrement dit, vous pouvez lui donner des attributs et même des méthodes privées. Si, dans votre contrôleur, vous
devez exécuter régulièrement les mêmes instructions, créez une méthode privée pour éviter la redondance de votre code.
Si votre méthode est privée, elle ne sera pas accessible par l'URL (tout comme les méthodes commençant par un
underscore _).
Méthodes spéciales
CodeIgniter a prévu pour vous certaines particularités dans les contrôleurs. Nous allons les voir tout de suite.
La méthode index
Cette méthode a la particularité d'être appelée dans le cas où votre URL ne spécifie pas de nom de méthode.
Un exemple est toujours plus parlant :
<?php
class Forum extends CI_Controller
{
public function index()
{
echo 'Index';
}

public function accueil()

{
echo 'Hello World!';
}
}
Lorsque vous irez sur ces trois URL, vous appellerez donc la méthode index.
• forum/
• forum.html avec l'extension.
• forum/index.html
Vous verrez donc s'afficher le message « Index ».
Astuce
N'oubliez pas que vous êtes dans une classe. Rien ne vous empêche de faire ceci :
<?php
class Forum extends CI_Controller
{
public function index()
{
$this->accueil();
}

public function accueil()

{
echo 'Hello World!';
}
}
Mon exemple est trop simple, car vous remplacez une ligne par une autre. Mais dans le cas d'une méthode accueil assez
importante, cela peut être intéressant.
Cette technique est applée « redirection interne », car elle est invisible depuis un navigateur.
Le constructeur
Encore une méthode intéressante, le constructeur. Dans les contrôleurs, vous utiliserez cette méthode pour effectuer des
tâches d'initialisation. Autrement dit, vous allez placer tout le code qui devra être exécuté à chaque fois que vous allez sur
l'une des pages de ce contrôleur. C'est particulièrement utile si vous devez initialiser des attributs ou charger des
bibliothèques et des helpers (que nous verrons plus loin).
Une petite remarque : si vous implémentez le constructeur, vous devez absolument exécuter le constructeur de la classe
mère avant de commencer votre code.
Exemple :
<?php
class Forum extends CI_Controller
{
private $titre_defaut;

public function __construct()

{
// Obligatoire
parent::__construct();

// Maintenant, ce code sera exécuté chaque fois que ce contrôleur sera appelé.
$this->titre_defaut = 'Mon super site';
echo 'Bonjour !';
}

public function index()

{
$this->accueil();
}
public function accueil()
{
var_dump($this->titre_defaut);
}
}
Si vous retournez sur une page de ce contrôleur, vous verrez donc le message « Bonjour ! » et la variable sera initialisée.
Mais regardons un autre exemple. L'authentification est prévue pour un autre chapitre, mais vous savez que les
contrôleurs doivent faire attention aux différents niveaux d'authentification. Il pourrait exister par exemple un module
entièrement réservé aux administrateurs. Pour cela, il suffira de placer une condition dans le constructeur pour que toutes
les pages de celui-ci soient protégées.
<?php
class Admin extends CI_Controller
{
public function __construct()
{
// Obligatoire
parent::__construct();

if( ! isAdmin())
exit("Vous n'avez pas le droit de voir cette page.");
}

public function activer_maintenance()

{
/* ---- */
}
public function ajouter_rang()
{
/* ---- */
}
}
Cela permettra de faire rapidement le tri entre les administrateurs et les autres. À vous d'utiliser cette méthode comme bon
vous semble.
La méthode _output
La méthode _output vous permet de manipuler une dernière fois les données que vous allez envoyer au navigateur.
Cette fonction n'est pas accessible depuis le navigateur, car elle est précédée d'un « _ » (underscore).
Output en anglais signifie « sortie ».
<?php
class Forum extends CI_Controller
{
public function __construct()
{
// Obligatoire
parent::__construct();
}

public function index()

{
$this->accueil();
}
public function accueil()
{
 echo 'Bonjour';
}
// L'affichage de la variable $output est le comportement par défaut.
public function _output($output)
{
var_dump($output);
}
}
Si vous effectuez quelques tests, vous verrez que cette méthode n'a aucun effet parce que le contrôleur ne doit pas
afficher de texte. Nous verrons bientôt l'utilisation des vues. Vous pourrez l'utiliser ensuite.
La méthode _remap
_remap est une méthode très puissante. Elle vous permet de modifier la méthode que vous allez utiliser. Autrement dit,
faire une redirection interne un peu plus dans le style de CodeIgniter. Nous allons voir un exemple d'utilisation de cette
fonctionnalité mais nous l'étudierons plus en détail dans le chapitre portant sur le routeur.
Voici un exemple d'utilisation. Nous allons rediriger toutes les URL du contrôleur vers la page de maintenance.
<?php
class Home extends CI_Controller
{
public function accueil()
{
echo 'Bonjour';
}

public function maintenance()

{
echo "Désolé, c'est la maintenance.";
}

public function _remap($method)

{
$this->maintenance();
}
}
Quelle que soit l'URL, ce sera toujours la méthode maintenance qui sera appelée. Il s'agira donc d'une redirection interne
en continu...
À partir du moment où vous allez implémenter cette méthode, vous devrez le faire jusqu'au bout. Si vous n'y mettez rien,
alors aucune méthode ne sera appelée. Vous devrez donc faire la vérification de l'existence de la page. Si vous souhaitez
afficher la page d'erreur 404, vous pouvez utiliser la méthode show_404() pour l'afficher.
Vous connaissez désormais tout ce qu'il faut savoir sur les contrôleurs. Le contrôleur n'est pas un élément très complexe,
mais il ne vous permet pas de faire de vraies pages web à la sauce CodeIgniter.
La vue
Vous savez maintenant comment créer des contrôleurs avec CodeIgniter. Maintenant, nous allons aborder les vues.
Les vues sont composées de code HTML et d'un peu de PHP. Ce sont les données qui sont envoyées au navigateur.
Votre première vue
Création de la vue
Pour créer une vue, vous devez tout d'abord créer un fichier dans le dossier ./application/views/. Placez-y tout ce que vous
voulez.
Dans ce cas, écrivons le contenu dans un fichier vue.php :
<h1>Bonjour</h1>
<p>
Ceci est mon paragraphe !
</p>
Rien de particulier. Un titre et un paragraphe.
Chargement de la vue
Lorsque vous avez fini de créer votre vue, vous devez l'afficher via le contrôleur. Voici comment il faut faire.
<?php
class News extends CI_Controller
{
public function __construct()
{
parent::__construct();
}

public function index()

{
$this->accueil();
}
public function accueil()
{
$this->load->view('vue');
}
}
Cette ligne vous permet d'afficher le contenu de la vue. Le premier paramètre attend donc le nom du fichier sans
l'extension.
Transférer vos variables
Pour transférer des variables du contrôleur à la vue, nous allons dans un premier temps créer un tableau qui contiendra
toutes les données à transmettre à la vue.
<?php
class News extends CI_Controller
{
public function index()
 {
$this->accueil();
}
public function accueil()
{
$data = array();
$data['pseudo'] = 'Arthur';
$data['email'] = '[email protected]';
$data['en_ligne'] = true;
$this->load->view('vue');
}
}
Maintenant que nous avons notre tableau de variables, nous allons pouvoir le donner à la vue. Pour cela, il faut utiliser le
2e argument de la méthode view.
<?php
class News extends CI_Controller
{
public function index()
{
$this->accueil();
}
public function accueil()
{
$data = array();
$data['pseudo'] = 'Arthur';
$data['email'] = '[email protected]';
$data['en_ligne'] = true;

// Maintenant, les variables sont disponibles dans la vue

$this->load->view('vue', $data);
}
}
Modifions la vue pour y faire apparaître les variables.
Les variables sont retirées de leur tableau. Depuis la vue, la variable $data n'existera pas. En revanche, les variables
$pseudo, $email et $en_ligne seront bien présentes.
<h1>Bonjour</h1>
<p>
Ceci est mon paragraphe !
</p>
<p>
 Votre pseudo est <?php echo $pseudo; ?>.
</p>
<p>
Votre email est <?php echo $email; ?>.
</p>
<p>
<?php if($en_ligne): ?>
Vous êtes en ligne.
<?php else: ?>
Vous n'êtes pas en ligne.
<?php endif; ?>
</p>
Maintenant, vous savez comment transférer des variables du contrôleur à la vue.
Quelques fonctionnalités sur les vues
Gestion des dossiers
Vous avez la possibilité de créer des dossiers dans le répertoire views. Une bonne habitude consiste à classer ses vues en
fonction du contrôleur. Autrement dit, vous allez placer toutes les vues du contrôleur News dans le dossier
./application/views/news/.
Pour appeler ces vues, vous devrez donner le chemin relatif avant le nom de la vue à afficher.
<?php
$this->load->view('news/vue');
A vous d’organiser convenablement vos vues. N'hésitez pas à créer des dossiers.
Charger plusieurs vues
Certaines personnes n'y pensent pas toujours, ajoutons donc une petite partie uniquement pour elles. Vous pouvez charger
autant de vues que vous voulez.
<?php
public function accueil()
{
$this->load->view('theme/en_tete');
$this->load->view('theme/menu_gauche');
$this->load->view('theme/menu_droit');
$this->load->view('news/accueil');
$this->load->view('theme/footer');
}
Si vous devez constamment charger des vues, vous avez la possibilité de les placer dans le constructeur du contrôleur.
Toutes les instructions seront exécutées et cela compte aussi pour les vues. Nous verrons dans une autre partie comment
inclure automatiquement l'en-tête et le pied-de-page. Donc ne vous ennuyez pas trop avec vos thèmes et vos layouts.
Sauvegarder le contenu de vos vues
Le problème avec la méthode view, c'est qu'elle affiche tout le temps le contenu de la vue. Alors si vous voulez
sauvegarder dans un fichier le contenu de ce qui va s'afficher (faire un système de cache), vous serez bloqués.
Pour résoudre cela, vous pouvez utiliser le 3e argument de la méthode view. C'est un booléen. Si sa valeur est false
(défaut), alors la vue sera affichée. Par contre, si la valeur est true, alors cette méthode retournera le contenu de la vue
mais ne l'affichera pas.
<?php
public function accueil()
{
$data = array;
$data['pseudo'] = 'Arthur';
$data['email'] = '[email protected]';
$data['en_ligne'] = true;

$vue = $this->load->view('vue', $data, true);

}
Vous savez maintenant créer des contrôleurs et des vues. N'hésitez pas à construire un petit site web pour effectuer vos
tests. Avec les contrôleurs et les vues, il y a déjà pas mal à faire.
Nous n'aborderons pas les modèles dès le prochain chapitre, car nous n'avons pas encore appris à lancer des requêtes à la
base de données. Nous allons donc d'abord nous préparer en découvrant les helpers et les bibliothèques, puis nous finirons
par les modèles.
Les helpers
Dans la partie I, les helpers constituent un ensemble de fonctions réunies par thème. Vous n'allez donc pas charger une
fonction à la fois mais un ensemble de fonctions.
Nous allons donc voir comment charger un helper. Ensuite, nous apprendrons à créer les nôtres et même à modifier les
helpers natifs.
Charger et utiliser les helpers
Pour charger un helper, vous allez voir, c'est très simple. Et pour les utiliser, c'est encore plus simple, car il ne s'agit que
de simples fonctions. J'espère que vous êtes au point avec les fonctions...
Charger un helper
Pour charger un helper depuis un contrôleur, nous allons utiliser cette instruction :
<?php
$this->load->helper('nom');
Si vous voulez charger plusieurs helpers en même temps, il est possible de passer en paramètre un tableau au lieu d'une
chaîne de caractères.
La liste des helpers est disponible ici, dans la colonne de droite.
Utilisation du helper url
Nous allons apprendre à nous servir du helper url.
Commençons par le charger :
<?php
$this->load->helper('url');
À partir de maintenant, vous pourrez utiliser les fonctions de ce helper dans votre contrôleur, mais aussi dans votre vue.
Si vous aviez entré dans votre autoloader (./application/config/autoload.php) le nom de ce helper, alors vous n'avez pas
besoin de le charger avant de l'utiliser.
Voici un contrôleur et une vue classique pour pouvoir tester ces fonctions :
<?php
class Test extends CI_Controller
{
public function __construct()
{
parent::__construct();

// « Décommenter » cette ligne pour charger le helper url

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

public function accueil()

{
// On inclut la vue ./application/views/test/accueil.php
$this->load->view('test/accueil');
}
<h1>
Test
</h1>
Fonction site_url
Nous allons commencer par la fonction la plus importante : site_url.
Cette fonction permet de retourner une URL. C'est donc avec cette fonction que nous allons créer toutes les URL à partir
de maintenant.
Pourquoi ?
Car cela va rendre vos URL beaucoup moins dépendantes de votre environnement, et donc beaucoup plus flexibles !
En utilisant cette fonction, vous ne devrez plus donner votre nom de domaine, ni le fichier index.php (imaginez que vous
changez d'hébergeur et qu'il n'y ait plus l'URL rewriting), ni l'extension. Vous êtes libres de modifier toutes vos URL en
même temps grâce à cette fonction.
Désormais, je l'utiliserai constamment pour poursuivre ce tutoriel.
Il y a deux façons de construire son URL : avec une chaîne de caractères et avec un tableau.
<h1>
Test
</h1>
<p>
<a href="<?php echo site_url(); ?>">accueil</a>
<br />
 <a href="<?php echo site_url('test'); ?>">accueil</a> du test
<br />

<a href="<?php echo site_url('test/secret'); ?>">page secrète</a>

<br />

<a href="<?php echo site_url(array('test', 'secret')); ?>">page secrète</a>

</p>
Fonction redirect
La fonction redirect fonctionne de la même manière que site_url. Elle permet d'effectuer une redirection de type
« location ». Elle accepte en paramètre une chaîne de caractères ou un tableau.
<?php
class Test extends CI_Controller
{
public function __construct()
{
parent::__construct();

// Décommenter cette ligne pour charger le helper url

//$this->load->helper('url');
}
public function index()
{
redirect(array('error', 'probleme'));
}

public function accueil()

{
$this->load->view('test/accueil');
}
D'autres fonctions
current_url Cette fonction renvoie l'URL de la page actuelle.

Cette fonction renvoie votre URL, mais sans les segments (variables GET, nom du contrôleur, nom de la
base_url méthode...). Dans la plupart des cas, ce sera votre nom de domaine. Par exemple, sur le SdZ, cette fonction
retournera http://www.siteduzero.com/
Je ne vous ai présenté que les fonctions les plus importantes de ce helper. Je vous laisse découvrir les autres dans la
documentation.
L'utilisation d'un helper est relativement simple. Vous le chargez et vous utilisez ses fonctions. Sauf que durant votre
développement, vous pourrez avoir besoin d'ajouter des fonctions aux helpers, voire d'en créer d'autres. C'est ce que nous
allons faire dès maintenant.
Création du helper « assets »
Nous allons maintenant réaliser un helper assets. Celui-ci permettra de récupérer plus rapidement les URL des fichiers
contenus dans le dossier assets. Il comportera quatre fonctions.
Prototype Description
string css_url ( string $nom ) Permettra de retourner l'URL d'un fichier CSS.
string js_url ( string $nom ) Permettra de retourner l'URL d'un fichier JavaScript.
string img_url ( string $nom ) Permettra de retourner l'URL d'une image.
void img ( string $nom , string $alt = '') Permettra de créer rapidement le code HTML des images.
Pour créer un nouveau helper, il faut créer un fichier dans le dossier ./application/helpers/ . Nous l'appellerons
assets_helper (oui, le suffixe est obligatoire). Ensuite, il faut l'inclure via l'autoloader ou manuellement :
<?php $this->load->helper('assets');
Ce helper utilisera des fonctions du helper URL. Vous devrez donc veiller à l'inclure soit via l'autoloader, soit depuis
votre contrôleur avant de l'utiliser.
Fonction css_url
Cette fonction attend un paramètre qui devra être une chaîne de caractères. Il nous suffit donc simplement d'ajouter le
nom de domaine avant, puis le chemin, ensuite le paramètre et enfin l'extension.
Le nom de domaine sera récupéré via la fonction base_url.
Eh bien allons-y !
<?php
function css_url($nom)
{
return base_url() . 'assets/css/' . $nom . '.css';
}
Cette petite fonction nous permettra de déplacer très facilement le dossier assets sans réécrire toutes les URL pour inclure
les fichiers CSS.
Fonction js_url
Rien de nouveau dans cette fonction. C'est quasiment la même que css_url.
<?php
function js_url($nom)
{
return base_url() . 'assets/javascript/' . $nom . '.js';
}
Fonction img_url
Il y a un petit piège dans cette fonction, mais je suis sûr que vous ne tomberez pas dedans !
<?php
function img_url($nom)
{
return base_url() . 'assets/images/' . $nom;
}
En effet, cette fonction ne peut pas connaître à l'avance l'extension de l'image, contrairement aux fichiers CSS et
JavaScript.
Fonction img
Cette fonction attend deux paramètres. Le premier est le nom de l'image. Nous allons donner cette variable directement à
la fonction img_url. Le deuxième paramètre sera pour l'attribut alt de l'image. Il est donc facultatif.
<?php
function img($nom, $alt = '')
{
return '<img src="' . img_url($nom) . '" alt="' . $alt . '" />';
}
Notre helper assets
Voici donc notre helper assets. J'ai encadré toutes les fonctions avec une condition pour éviter de redéfinir des fonctions.
Nous allons voir tout de suite après qu'il y a aussi une autre raison à cela.
<?php if ( ! defined('BASEPATH')) exit('No direct script access allowed');
if ( ! function_exists('css_url'))
{
function css_url($nom)
{
return base_url() . 'assets/css/' . $nom . '.css';
}
}
if ( ! function_exists('js_url'))
{
function js_url($nom)
{
return base_url() . 'assets/javacript/' . $nom . '.js';
}
}
if ( ! function_exists('img_url'))
{
function img_url($nom)
{
return base_url() . 'assets/images/' . $nom;
}
}
if ( ! function_exists('img'))
{
function img($nom, $alt = '')
{
return '<img src="' . img_url($nom) . '" alt="' . $alt . '" />';
 }
}
La première ligne du fichier permet d'exécuter le script seulement si la constante BASEPATH est définie. En fait, elle est
créée au tout début du fichier index.php. En faisant cela, vous serez assurés que le script ne sera pas exécuté depuis
l'URL, mais bien en suivant l'ordre normal des choses.
Désormais, vous savez comment créer entièrement un helper. Cela permettra de diminuer grandement la redondance de
votre application. Maintenant, nous allons voir comment redéfinir et même ajouter quelques fonctions à un helper natif.
Modifier un helper
Créer le fichier
Une fonction ne vous convient pas dans un helper ? Vous avez envie de rajouter une fonction dans un helper ? Voyons
tout de suite comment nous allons faire.
Retournez dans votre fichier de configuration (config.php) et cherchez cette ligne :
<?php
$config['subclass_prefix'] = 'MY_';
Elle vous indique le préfixe du nom que doit avoir votre fichier pour modifier le comportement d'un script natif de
CodeIgniter. Si vous appelez votre fichier MY_url_helper.php, vous allez pouvoir réécrire les fonctions du helper url. En
fait, notre fichier va être lancé avant le helper natif. Nous y définissons des fonctions telles que site_url, ou current_url.
Puis une fois arrivé au bout du fichier, CodeIgniter appellera le helper natif.
Mais nous allons définir deux fonctions avec le même nom, alors ?
Non ! Car si vous vous souvenez de la partie précédente, chaque fonction est entourée d'une condition :
<?php
if ( ! function_exists('site_url'))
{
function site_url($uri = '')
{
/* ****** */
}
}
Donc nous définissons les fonctions que nous voulons changer dans notre fichier MY_url_helper.php, puis CodeIgniter se
chargera d'inclure toutes les autres fonctions que nous n'avons pas réécrites.
Créons donc notre fichier MY_url_helper.php dans le dossier ./application/helpers/.
Modification de la fonction site_url
Nous allons modifier la fonction site_url. Pourquoi ? Parce que j'ai envie de lui offrir la possibilité de lui passer autant de
paramètres que l'on souhaite.
<?php
$url_secret = site_url('forum', 'secret', '2452', 'codeigniter');
/*
$url_secret va donc valoir quelque chose comme cela :
http://nom_de_domaine.tld/forum/secret/2452/codeigniter.html
*/
L'implémentation est assez simple, car nous allons seulement modifier l'en-tête de la fonction. Nous ne toucherons pas au
reste. Voici la fonction d'origine :
<?php
if ( ! function_exists('site_url'))
{
function site_url($uri = '')
{
$CI =& get_instance();
return $CI->config->site_url($uri);
}
}
Vous ne comprendrez sûrement pas le code de cette fonction, car elle fait appel à des notions que nous allons voir
immédiatement après ce chapitre. En fait, cette fonction est délocalisée. Les instructions ne sont pas dans la fonction mais
dans une autre partie de CodeIgniter.
Dans notre cas, nous ne modifierons pas cette partie.
Voici ce que nous allons faire : si le premier paramètre est un tableau, nous ne modifions rien. Mais si le premier
paramètre est une chaîne de caractères, alors nous allons créer un tableau avec tous les paramètres envoyés à la fonction.
Cela s'implémente très facilement avec la fonction func_get_args qui permet de retourner sous forme de tableau tous les
paramètres envoyés à notre fonction.
<?php
function site_url($uri = '')
{
if( ! is_array($uri))
{
// Tous les paramètres sont insérés dans un tableau
$uri = func_get_args();
}

// On ne modifie rien ici

$CI =& get_instance();
return $CI->config->site_url($uri);
}
Désormais, la fonction site_url aura un comportement différent.
Mais pourquoi n'a-t-on pas créé un autre helper ?
Parce que ça n'aurait pas de sens. Vous auriez dû appeler deux helpers pour gérer vos URL. Modifier les helpers natifs de
cette façon est une très bonne habitude. Je vous rappelle qu'il est fortement déconseillé de modifier tout code présent dans
le dossier ./system/.
Ajout de la fonction url
C'est un peu bête d'avoir fait tout ça pour modifier trois lignes... Je vous ai donc concocté une autre fonction : url. Elle
permet de créer rapidement des liens. Elle prendra en premier paramètre le texte à insérer dans le lien. Et en second
paramètre, nous créons le lien de la même façon que la fonction site_url.
<?php
// Affichera (selon les préférences) : <a href="http://nom_de_domaine.tld/user/connexion.html">Page de connexion</a>
url('Page de connexion', 'user', 'connexion');
Voici le code de cette fonction.
<?php
function url($text, $uri = '')
{
if( ! is_array($uri))
{
$uri = func_get_args();
// Suppression de la variable $text
array_shift($uri);
}

echo '<a href="' . site_url($uri) . '">' . htmlentities($text) . '</a>';

return '';
}
Vous noterez que nous avons utilisé la fonction array_shift en plus. Elle permet d'envoyer à la fonction site_url tous les
paramètres que nous avons reçus sauf un : le texte.
Notre fichier MY_url_helper.php
Voici donc notre ficher MY_url_helper.php :
<?php if ( ! defined('BASEPATH')) exit('No direct script access allowed');
if ( ! function_exists('site_url'))
{
function site_url($uri = '')
{
if( ! is_array($uri))
{
// Tous les paramètres sont insérés dans un tableau
$uri = func_get_args();
}

// On ne modifie rien ici

$CI =& get_instance();
return $CI->config->site_url($uri);
}
}
// ------------------------------------------------------------------------
if ( ! function_exists('url'))
{
function url($text, $uri = '')
{
if( ! is_array($uri))
{
// Suppression de la variable $text
$uri = func_get_args();
array_shift($uri);
}

echo '<a href="' . site_url($uri) . '">' . htmlentities($text) . '</a>';

return '';
}
}
/* End of file MY_url_helper.php */
/* Location: ./application/helpers/MY_url_helper.php */
Pourquoi la surcharge du helper url possède-t-elle toujours les conditions d'existence des fonctions ?
Question tout à fait légitime. J'y répondrai par une autre question : et si quelqu'un voulait réécrire les fonctions que nous
avons réécrites ?
En fait, si vous voulez réécrire encore une fois les fonctions, vous n'allez pas passer par un troisième fichier. Vous allez
réécrire les fonctions de votre fichier, celui qui est dans le dossier application.
Donc ça ne sert à rien ?
Non plus ! Je vais reformuler une autre question : et si quelqu'un voulait réécrire les fonctions que nous avons réécrites
mais seulement une seule fois ? Ça évite les risques de redéfinir une fonction qui est déjà définie dans un autre helper.
Cette partie vous a permis de bien comprendre la notion de helpers dans CodeIgniter. N'hésitez pas à créer les vôtres si
votre code devient trop redondant.
Cependant, l'utilisation de helpers n'est pas l'unique moyen d'éviter la redondance. Dans le prochain chapitre, nous
verrons un autre outil : les bibliothèques.