CodeIgniter, le framework PHP léger

CodeIgniter est un framework d'application Web pour les développeurs qui préfèrent la vitesse à un grand choix de fonctions. Selon la page officielle de CodeIgniter, l'objectif principal du framework PHP open-source est d'offrir un maximum de performance et de flexibilité dans une structure de programmation la plus simple possible.

CodeIgniter : qu’est-ce que c’est ?

CodeIgniter est un framework Web écrit en PHP, qui vante une conception logicielle compacte rendant le développement d'applications Web plus rapide et plus efficace. CodeIgniter a été créé par la société américaine de logiciels EllisLab, qui a publié sa première version en février 2006. Le 9 juillet 2013, EllisLab annonce qu'elle n’est plus en mesure de réunir seule les ressources nécessaires pour poursuivre le développement du logiciel. Un an plus tard, le projet est donc repris par le British Columbia Institute of Technology (BCIT). Le code source du framework est sous licence MIT et peut être obtenu à partir du service en ligne GitHub. La dernière version stable, CodeIgniter 3.1.2, est disponible en téléchargement gratuit sur la page officielle du projet depuis octobre 2016.

Construction et structure du framework

La conception orientée performance de CodeIgniter se reflète dans la construction allégée du framework PHP. Elle est basée sur le modèle d'architecture logicielle appelé Modèle-Vue-Contrôleur (MVC). Le principe fondamental du MVC est la séparation stricte du code du programme et de la présentation. Elle est réalisée par une structure logicielle modulaire et l'externalisation du code PHP. On différencie alors trois composants centraux : le modèle de données (modèle), la présentation (vue) et le contrôleur.

  • Le modèle représente la structure de données d'une application Web développée sur la base de CodeIgniter. Pour cela, des classes de modèles sont définies dans le code source. Il s'agit notamment de fonctions spéciales qui permettent d'extraire des informations d'une base de données, de les stocker ou de les mettre à jour.
  • La vue est la partie de l’application qui est présentée à l'utilisateur final. Il s'agit en principe d'un document HTML dans lequel le contenu est intégré dynamiquement via PHP. Une vue est donc en quelque sorte comparable à un template. CodeIgniter offre également la possibilité de définir en tant que vue des fragments de page Web tels que les en-têtes et pieds de page, ou encore des pages RSS. En règle générale, les applications Web utilisent plusieurs vues qui tirent leur contenu du même modèle de données. Ceci permet de présenter les différentes caractéristiques du programme dans différentes vues.
  • Le contrôleur sert d'instance de médiation entre le modèle, la vue et toute autre ressource nécessaire au traitement d'une requête HTTP ou à la création dynamique d'une page Web. Ce composant accepte les requêtes entrantes, valide les entrées, recherche la vue souhaitée et lui transmet les contenus que le modèle de données a chargé d'une base de données.

Le graphique suivant montre de manière schématisée comment les composants MVC interagissent :

Représentation schématisée du modèle d’architecture MVC
Interaction entre les composants MCV : Modèle, Vue, Contrôleur

La structure MVC permet une conception logicielle flexible, dans laquelle les modules de programme peuvent tous être échangés, révisés et réutilisés en un minimum d'efforts. Les modifications apportées à un composant n'ont en principe pas d'effet sur le code source des autres composants (à condition qu'aucune modification ne soit apportée aux interfaces).

La séparation stricte entre la logique et la présentation du programme garantit un code de programmation clair et bien structuré. La maintenance des applications Web basées sur MVC est normalement assez simple. En cas d'erreur, la recherche du dysfonctionnement se limite dans la plupart des cas à l’un des composants.

Par ailleurs, le modèle d'architecture MVC offre la possibilité de développer de manière séparée la logique et la mise en page d'une application web. Si les développeurs back-end et front-end travaillent en parallèle, les applications peuvent être complétées beaucoup plus rapidement.

CodeIgniter utilise MVC, mais ne lie pas complètement les utilisateurs à ce modèle architectural. Si Contrôleur et Vue constituent des composants obligatoires, les connexions aux bases de données via le modèle sont quant à elles facultatives. De plus, une application basée sur CodeIgniter peut également être implémentée avec une architecture MVC hiérarchique (HMVC) qui étend le modèle classique MVC à une logique hiérarchique.

Flux d'application du framework PHP

CodeIgniter est basé sur un concept d'URL. Cela signifie que le contrôleur en tant qu'unité centrale de commande entre la vue et le modèle est sollicité en entrant une URL dans la barre de recherche du navigateur Web. Les développeurs créent à cette fin des classes contrôleurs. Il s'agit de fichiers PHP qui contiennent diverses fonctions pour charger des bibliothèques (libraries), des extensions (plugins) ou des classes d'aide (helper), pour se connecter à des bases de données, pour intégrer des modèles de données, ou encore pour rechercher une vue spécifique.

Le flux d'application de CodeIgniter est ainsi basé sur le schéma URL de base suivant :

exemple.com/class/function/parameter

Le nom de domaine (exemple.com) est suivi d'une classe contrôleur à adresser et d'une fonction de contrôleur spécifique. Les paramètres optionnels terminent le schéma. Ces derniers servent à transmettre les ID ou variables au contrôleur sélectionné.

En pratique, une URL CodeIgniter pourra ressembler à ceci :

exemple.com/news/article/511

Une telle URL s’adresse au contrôleur news sur le nom de domaine exemple.com et l'amène à exécuter la fonction article (par exemple, pour charger une vue du même nom pour la visualisation de l’article). Les paramètres optionnels qui sont transmis au contrôleur avec l'URL spécifient quels contenus doivent être récupérés de la base de données via le modèle de données - dans cet exemple, un article avec ID 511.

Dans la configuration de sortie, CodeIgniter comprend index.php dans chaque URL d'application :

exemple.com/index.php/news/article/511

Ce fichier PHP contient des informations sur l'emplacement des fichiers de base du framework ainsi que les bibliothèques, extensions ou classes d'aide associées, et indique dans quel répertoire se trouvent les fichiers de l'application. index.php est utilisé pour initialiser toutes les ressources de base.

Si CodeIgniter s'exécute sur un serveur Apache HTTP, index.php peut être supprimé des URL de l'application via mod_rewrite, de sorte que les utilisateurs et crawlers des moteurs de recherche puissent disposer d’adresses Web « propres ». Les développeurs ajoutent alors au fichier .htaccess du serveur Web le bloc de code suivant:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1 [L]

La structure de base du framework PHP est basée principalement sur les classes contrôleurs, les classes de modèles et les templates de vues.

Classes contrôleur

CodeIgniter offre aux développeurs la possibilité de programmer des contrôleurs individuels en tant que classes personnalisées. Pour ce faire, les développeurs Web disposent d’un fichier PHP distinct pour chaque contrôleur dans le répertoire application/controllers/. Les contrôleurs contiennent la logique de programme d'une application Web développée avec CodeIgniter et sont créés en tant que sous-classes de CI_Controller class. Les programmeurs y procèdent en utilisant dans le code source le mot-clé extends.

class News extends CI_Controller {
}

En tant que classe enfant, News hérite de la part de la classe parent CI_Controller de toutes les fonctions sur la visibilité public et protected.

Remarque

Les mots-clés public, protected ou private sont utilisés en PHP pour définir la visibilité d'une propriété ou d'une fonction. Si un élément est déclaré public, toutes les classes d'un logiciel vont avoir accès à l'élément. Pour restreindre cet accès aux classes parents et aux classes dérivées, les programmeurs utilisent le mot-clé protected. Un élément déclaré comme privé (private) n'est disponible que pour la classe qui définit l'élément.

Chaque classe contrôleur personnalisée doit également inclure une fonction construction qui permet d'intégrer des bibliothèques, un modèle de données, des bases de données ou des classes d'aide. A partir de PHP5, __construct() est utilisé comme une fonction constructeur standardisée.

<?php
class News extends CI_Controller {
    public function __construct() {        //définit le constructeur 
        parent::__construct();        //récupère le constructeur de la classe parent
        $this->load->helper('url');        // charge une classe helper pour travailler avec les URL
        $this->load->helper('file');        //charge une classe helper pour travailler avec les fichiers 
        $this->load->database();        //charge une base de données
        $this->load->model('News_model');    //charge un modèle du nom « News_model » 
}
?>

L'exemple présente la classe News comme sous-classe de CI_Controller. La fonction constructeur __construct() intègre deux classes « helper », une base de données et le modèle de données News_model. Les différentes lignes de code sont commentées dans le code source.

Note

Toutes les classes contrôleurs définies en PHP pour CodeIgniter doivent commencer par une lettre majuscule (News et non news). Dans l'URL, on utilise en revanche les lettres minuscules.

Fonction Contrôleur

Si la structure de base du contrôleur personnalisé est définie, la logique de programmation proprement dite va suivre sous la forme de fonctions contrôleur, permettant par exemple d’appeler les vues ou encore d’établir des interactions avec un modèle de données.

Pour permettre au contrôleur de charger une vue, le document HTML sous-jacent doit être stocké en tant que fichier PHP dans le répertoire application/views/. Une vue simple pourrait ainsi ressembler à ceci pour une visualisation d'article :

<!DOCTYPE html>
<html lang="de">
  <head>
    <meta charset="utf-8">
    <title><?php echo $title; ?></title>
 </head>
 <body >
    <h1><?php echo $headline ?></h1>
    <p><?php echo  $content_body ?></p>
 </body>
</html>
Remarque

les documents HTML contenant du code PHP doivent être sauvegardés sous forme de fichiers PHP (.php). C'est la seule façon de s'assurer que l'interpréteur PHP du serveur Web exécute les scripts et ne se contente pas de sortir le code PHP sous forme de texte.

Pour charger une vue dans le contrôleur, il est nécessaire que l’utilisateur définisse une fonction. L'exemple de code suivant utilise la fonction article() pour charger la vue article.php.

public function article() {
    if (!file_exists(application/views/article.php)) {
        show_404();
    }
$this->load->view('article');
}

Le code du programme se lit comme suit : tout d’abord, CodeIgniter vérifie si le répertoire application/views/ contient un fichier nommé article.php. Cette requête est réalisée grâce à if et à la condition négative (!file-exists().

Si la condition est vraie et qu'il n'existe pas de fichier du même nom dans le répertoire correspondant, if renvoie la valeur TRUE, et CodeIgniter exécute la fonction show_404() listée sous if. Dans ce cas, l'utilisateur sera informé que le fichier demandé n'existe pas. Si la condition if n'est pas remplie et que !file_exists est donné FAUX (false), CodeIgniter exécute la fonction $this->load->view('article'). Cette dernière permet de charger le fichier correspondant pour la vue de l'application.

A partir du moment où l’on a un format PHP, le fichier désiré peut être énuméré dans la fonction view() sans suffixe. Si d'autres formats doivent être chargés, les suffixes de fichiers correspondants sont obligatoires.

CodeIgniter est généralement utilisé dans les applications Web dynamiques. Les utilisateurs se voient alors afficher des pages Web générées dynamiquement et non des pages HTML statiques.

exemple.com/news/article/511

Jusqu’ici, seule une vue a été chargée pour l'affichage de l’article grâce à la fonction $this->load->view('article'). Il est maintenant nécessaire d'intégrer les contenus liés au paramètre 511. Nous partons du principe qu'il s'agit d'un ID lié à un article donné du système de gestion de base de données. Pour le charger à partir de la base de données dans le programme, l'exemple ci-dessus doit être complété de manière à ce que le modèle de données inclus dans le constructeur soit pris en compte.

public function article($id) {
    if (!file_exists(application/views/article.php)) {
        show_404();
    }
    $data = $this->News_model->get_data($id);
    $this->load->view('article', $data);}

L'argument de fonction donné (ici sous le nom de la variable $id) correspond à l’ID de l'URL - par exemple, 511. La fonction modèle get_data(), qui doit encore être écrite, est utilisée pour charger le contenu de l'article associé à l'ID de la base de données. La méthode view() appelle article-View et lui transmet ses données ($data). Le modèle de données News_model transfère donc les données lues au Controller News, qui les transmet à la vue (view).

Toutes les opérations associées à la récupération des données sont transférées vers le modèle de données intégré.

Classes de modèles

Les modèles de données sont utilisés par CodeIgniter pour fournir des fonctions permettant d'exécuter certaines opérations de base de données. Tout comme les classes contrôleurs, les classes de modèles peuvent également être programmées avec le framework PHP.

Pour créer une classe de modèle, un nom de classe est d'abord attribué, à savoir ici News_model. Comme pour les classes contrôleurs, toutes les classes de modèle définies par l'utilisateur sont des sous-classes de la classe parent CI_Model. Le lien est établi par le mot-clé extends. Les classes de modèles intègrent également des bases de données et d'autres ressources via la fonction constructeur.

class News_model extends CI_Model {
    public function __construct() {
        parent::__construct();
        $this->load->database(); 
    }
}

Sur cette structure de base, on trouve ce que l'on appelle des fonctions de modèle, dans lesquelles les développeurs définissent toutes les opérations de base de données qui doivent être accessibles au contrôleur par le modèle de données correspondant.

Fonctions de modèle

Les classes de modèles permettent aux développeurs de définir des fonctions individuelles pour les opérations de base de données. Dans un exemple précédent, nous avons utilisé dans la classe contrôleur News la fonction get_data() définie par l'utilisateur pour charger le contenu de l'article de la base de données dans la vue. Dans le modèle, nous définissons maintenant quelles opérations de la base de données sont cachées derrière cette fonction.

class News_model extends CI_Model {
    public function __construct() {
        parent::__construct();
        $this->load->database(); 
    }
public function get_data($id) {
     $this->db->select('content');
     $this->db->from('example_table');
     $this->db->where('id', $id);
    $query = $this->db->get();
    return $query->result();
}

Dans la classe de modèle News_model, la fonction get_data() utilisée ci-dessus est définie comme opération de la base de données qui interroge via get() la colonne de l'enregistrement spécifié dans select() avec le numéro d'ID donné ($id) de la table de base de données spécifiée sous from() et la retourne sous forme de tableau en utilisant la fonction result(). Un modèle de données offre généralement un large choix de fonctions de modèle. Les développeurs peuvent ainsi utiliser la classe Query Builder, qui regroupe un certain nombre de fonctions prédéfinies pour les opérations classiques de la base de données. Vous pourrez en savoir plus dans la documentation officielle du framework CodeIgniter.

Routage avec CodeIgniter

La classe et la fonction du contrôleur à adresser sont spécifiées par CodeIgniter avec l’URL. Le framework Web utilise ainsi la structure d’URL classe/fonctions/paramètres. Ce schéma de base peut être adapté selon les besoins. CodeIgniter met par conséquent à disposition le fichier routes.php dans le répertoire application/config/. Il contient un tableau appelé $route, qui permet aux développeurs de définir leurs propres critères de routage.

Dans la configuration de sortie, trois entrées sont définies par défaut dans $route : le contrôleur standard, une règle de routage pour la redirection 404 et une règle pour remplacer automatiquement les traits d'union (-) par des tirets bas (_).

$route['default_controller'] = 'home/welcome';
$route['404_override'] = 'home/welcome';
$route['translate_uri_dashes'] = FALSE;

La première entrée détermine le contrôleur par défaut de l'application. Ce dernier sera chargé par CodeIgniter à chaque fois qu'une URL ne contient pas d’information sur le routage, hormis le domaine. Dans l'exemple ci-dessus, la règle de routage définit la classe de contrôleur home comme contrôleur par défaut. Les visiteurs qui ne procurent aucune information dans l’URL sur la page Web cible seront redirigés vers home et recevront la vue welcome. Généralement, une redirection vers la page d'accueil est opérée. Si aucun contrôleur n'a été défini par défaut, CodeIgniter affiche une page d'erreur 404 lorsque la page d'accueil est chargée.

La deuxième entrée par défaut dans $route définit un contrôleur qui est appelé chaque fois que le contrôleur adressé par l'URL n'est pas trouvé dans les fichiers de l'application. La règle de routage $route['404_override'] = 'home' écrase la page d'erreur 404 qui est normalement affichée dans ce cas et redirige à la place vers home de la classe contrôleur.

La troisième entrée par défaut de $route empêche les erreurs de routage dues aux traits d'union. Le tiret n'est pas un caractère valide pour les noms de classes ou de fonctions. Les paramètres par défaut le modifie donc automatiquement dans les URL.

Si une règle de routage définie par l'utilisateur doit être créée pour une URL dynamique, deux options se présentent aux développeurs avec CodeIgniter : les entrées de routage pour les URL dynamiques peuvent être définies grâce à des wildcards (métacaractères) ou des expressions régulières.

routes.php prend en charge deux types de métacaractère :

Note

Les sites Web contenant un grand nombre de pages d'erreur 404 sont difficiles à parcourir et ne facilitent pas l’accès des moteurs de recherche vers les contenus pertinents. Cela peut avoir une influence négative sur votre référencement naturel, mais aussi un mauvais impact sur l'expérience utilisateur. En règle générale, les développeurs Web s’efforcent donc autant que possible d'éviter les pages d'erreur 404.

Wildcards of routes.php Description
:num Métacaractère pour les nombre entier (Integer)
:any Métacaractère pour une chaîne de caractère (String)

L'exemple suivant montre une entrée dans routes.php qui permet de supprimer la fonction (article) de l'URL :

$route['news/article/(:num)'] = 'news/$1';

Le paramètre d'une URL dynamique va lire le métacaractère :num et le stocker dans la variable $1. Si vous définissez des règles de routage avec :num ou :any, vous devrez les mettre entre parenthèses dans routes.php.

routes.php accepte également les règles de routage sous forme d'expressions. Les deux caractères de remplacement vus ci-dessus peuvent ainsi être également notés comme suit :

num correspond à \d+
:any correspond à [^/]+

Une alternative à l'exemple ci-dessus serait la notation suivante :

$route['news/article/(\d+ )'] = 'news/$1';

Les expressions régulières nécessitent également des parenthèses dans routes.php.

Aperçu du flux d'application

Le graphique suivant résume les flux d'une application basée sur CodeIgniter en sept étapes :

Flux applicatifs du framework PHP CodeIgniter
Apercu de l’application flow du framework PHP CodeIgniter.
  1. index.php fait figure de front controller pour les requêtes HTTP entrantes de CodeIgniter. Toutes les ressources de base nécessaires à l'exécution de l'application sont initialisées.

  2. Dans le cadre du routage (routing), CodeIgniter vérifie quelle action doit être exécutée. Pour ce faire, l'application compare l'URL de la requête avec les règles de routage définies dans routes.php.

  3. La mise en cache fait suite au routage. Si une réponse correspondant à la requête se trouve dans le cache de l'application, elle est directement envoyée au navigateur Web qui a établi la demande. Sinon, le contrôleur déterminé lors du routage est exécuté avec une fonction de filtrage en amont.

  4. Le framework CodeIgniter contient un filtre intégré qui intercepte les requêtes malveillantes. Avant que l'application ne charge un contrôleur correspondant à une requête, chaque requête HTTP fait l'objet d'un contrôle de sécurité.

  5. Si la requête passe le filtre, le contrôleur est exécuté. Ce dernier sélectionne une vue appropriée et charge le modèle de données ainsi que toutes les bibliothèques, classes « helper », extensions et scripts qui sont nécessaires pour répondre à la requête.

  6. Dès que toutes les données pertinentes ont été transférées à la vue (view), elles peuvent être transmises au navigateur Web.

  7. Si la mise en cache est activée, CodeIgniter conserve temporairement les données sortantes afin de pouvoir répondre directement aux requêtes répétitives.

Avantages des frameworks CodeIgniter

Avec plus de 13 000 étoiles, CodeIgniter est un projet de développement GitHub très apprécié se classant au troisième rang des frameworks PHP les plus populaires. Mais comme tout logiciel, CodeIgniter présente à la fois des avantages et des inconvénients. Il est donc important de peser le pour et le contre avant de se décider d’opter pour le framework PHP. Voici les avantages de l'application :

  • Peu de configurations nécessaires : CodeIgniter permet un démarrage rapide. Les utilisateurs n'ont pas besoin de s’attarder longtemps sur les configurations, mais peuvent commencer à développer l'application souhaitée presque immédiatement après l'installation du framework. La configuration est essentiellement limitée aux paramètres de config.php dans le répertoire application/config/. Les utilisateurs définissent un chemin d'accès par défaut pour les navigateurs Web, une clé de cryptage, un nom pour le cookie de session et des paramètres pour le cross-site scripting (XSS). Il est également recommandé de créer un fichier .htaccess pour supprimer le fichier index.php du chemin URL de l'application via RewriteRule. En outre, une configuration pour se connecter à la base de données est nécessaire, ce que vous pourrez spécifier dans le fichier database.php.
  • Empreintes peu visibles : CodeIgniter ne laisse que peu de traces dans le système. Le package de téléchargement du framework représente environ 11 Mo. Plus de 9 Mo sont toutefois dus à la documentation détaillée du logiciel. La faible quantité de code est due au fait que le système de base CodeIgniter ne contient que quelques petites bibliothèques. Des ressources supplémentaires peuvent être chargées au besoin.
     
  • Très bonne performance : le système de base léger permet de procurer une bonne vitesse à CodeIgniter par rapport à d'autres frameworks PHP. Nombreux sont ceux qui en ont fait l’éloge, parmi lesquels Rasmus Lerdorf, l'inventeur de PHP. Ce dernier annonça en 2008 lors de la conférence Free and Open Source (FrOSCon) qu'il appréciait CodeIgniter car il était plus rapide, plus léger et se différenciait des frameworks courants (« because it is faster, lighter and the least like a framework »).
     
  • URL « propres » : CodeIgniter génère automatiquement des URL bien adaptés pour les moteurs de recherche. Au lieu d'utiliser des chaînes de requêtes pour accéder au contenu Web dynamique comme d'autres frameworks PHP, CodeIgniter utilise une approche segmentée.
    • URL avec chaîne de requête : example.com?controller=news&function=article&id=511
    • URL basée sur la segmentation : example.com/news/article/511.
  • Style de programmation libre : CodeIgniter est basé sur une interprétation libre du modèle d'architecture MVC. Cela signifie qu’un style de programmation n’est pas prédéfini pour les développeurs.
     
  • Documentation complète : CodeIgniter dispose d'une documentation complète en anglais, avec un tutoriel pour débutants. En outre, le code source est clair et bien commenté. La documentation de CodeIgniter est disponible sur son site Web officiel. Vous trouverez un guide en ligne ainsi qu’une version téléchargeable.
  • Communauté support : les programmateurs qui développent des applications basées sur CodeIgniter peuvent compter sur l'aide d'autres utilisateurs. Le projet est en effet soutenu  par une communauté active. Un forum public est accessible à l'adresse https://forum.codeigniter.com. Plus de 7 300 utilisateurs échangent leurs points de vue sur l'utilisation et le développement ultérieur du framework.

Inconvénients du framework CodeIgniter

Comme le développement du framework CodeIgniter a stagné un certain temps avant que le BCIT ne prenne le relais sur la gestion du logiciel, les programmeurs recherchent souvent des développements technologiques qui ont été adaptés par des frameworks similaires au cours des dernières années, mais pas par CodeIgniter.

  • ORM de fournisseurs tiers uniquement : le mapping objet-relationnel (ORM) est une technique de développement logiciel qui permet aux applications de stocker des objets écrits dans un langage de programmation orienté objet (tel que PHP) dans une base de données relationnelle. CodeIgniter ne prend initialement pas en charge l’ORM. Toutefois, la technologie peut être intégrée via un fournisseur tiers.
  • Pas de moteur de template : CodeIgniter se félicite de pouvoir s’en sortir sans moteur de template. Au lieu de cela, le framework met en option un analyseur de template simple à disposition. Certains considèrent cela comme un avantage car l’utilisation de moteur de template nécessite généralement un surplus de performance. De plus, il est souvent nécessaire d’apprendre à utiliser le langage du template. D’un autre côté, un moteur de template permet de séparer la production des données du code pour la présentation, ce qui conduit souvent à un code source clairement structuré. Si un moteur de template avec une syntaxe épurée est utilisé, cela peut réduire significativement la portée globale du code de l'application.
  • Pas d’espace de noms : avec les espaces de noms (namespaces), PHP offre la possibilité de séparer les codes de différents groupes d'applications. Les développeurs PHP profitent de cette fonctionnalité pour éviter les conflits qui peuvent être générés en nommant les classes et les fonctions. Typiquement, on voit souvent apparaître des collisions de noms avec des classes PHP internes, des fonctions, des constantes ou des éléments intégrés par des fournisseurs tiers. CodeIgniter n'utilise pas encore cette fonctionnalité PHP.
  • Pas d’auto-chargement de classes PHP : depuis la version 5, PHP propose avec __autoload() et spl_autoload_register() deux fonctions qui permettent de charger automatiquement les définitions de classes si nécessaire. Cette fonctionnalité n'est pas disponible dans le framework CodeIgniter.
  • Moins de bibliothèques intégrées que les autres frameworks PHP : en raison de la conception simplifiée du logiciel, CodeIgniter offre beaucoup moins de bibliothèques dans sa configuration que d’autres frameworks PHP. Il s'agit principalement des tâches les plus importantes du développement Web, telles que l'accès à la base de données, l’envoi d’emails, la validation des données de formulaires, la maintenance des sessions ou le travail avec XML-RPC. Pour les tâches qui vont au-delà des fonctionnalités de base, vous devez inclure vos propres bibliothèques ou ressources d’un fournisseur tiers. Cela peut toutefois être considéré comme un avantage par les développeurs qui recherchent un framework réduit au minimum.

CodeIgniter : données clés

Le tableau suivant présente un aperçu des données clés du framework CodeIgniter :

CodeIgniter    
Développeur British Columbia Institute of Technology (BCIT)  
Version actuelle Version 3.1.2  
Modèle de conception MVC/HMVC, Active Record, Chain of Responsibility  
Connaissances nécessaires PHP, programmation orientée objet (OOP)  
Langage de programmation PHP 5.6 ou plus  
Licence Licence MIT  
Compatibilité des bases de données MySQL (5.1+), Oracle, PostgreSQL, MS SQL, SQLite, CUBRID, Interbase/Firebird, ODBC  
ORM Uniquement via un fournisseur tiers  
Mise en cache oui  
Moteur de Template non  
Espaces de noms non  
PHP-Auto-Loading non  
URL « propres » oui  
Caractéristiques de sécurité Cross-Site-Request-Forgery (XSRF), Cross-Site-Scripting (XSS), SQL-Injection  
Testing library PHP Unit  
En résumé

Grâce à sa conception compacte et sa syntaxe simple, CodeIgniter est idéal pour les programmeurs en devenir. Si vous avez déjà une première expérience en développement Web dynamique basé sur PHP, vous vous adapterez en un rien de temps au framework basé PHP très léger. Les développeurs Web expérimentés apprécieront quant à eux sa flexibilité.

Cependant, toute personne qui souhaite utiliser CodeIgniter doit pouvoir faire au modèle d'architecture MVC et se passer d'un moteur de template ainsi que d'un mapping objet-relationnel natif. CodeIgniter reste malgré tout adapté aux petits et grands projets Web, et ce même s’il présente un code minimal.

Cet article vous a-t-il été utile ?