Cours : Code Igniter

Généralités

Ce cours a été fait sur la base de CodeIgniter 3. Il est désormais obsolète, et je vous encourage à revoir tous les concepts avec CI4. En revanche, pour des débutants, cela peut être un peu plus simple de commencer par ici si vous le voulez. Désolé, je travaillerai à la mise à jour des cours au plus tôt...

Lien vers la doc officielle de CodeIgniter 3 (EN) : https://codeigniter.com/userguide3/index.html

Forum

Annonces Forum

Présentation du concept de framework

Si vous êtes dans ce cours, c'est que vous savez déjà codé un minimum. Les concepts de base de la programmation n'ont déjà plus aucun secret pour vous, et vous avez déjà codé de nombreuses fonctionnalités au travers de vos expériences personnelles ou professionnelles.

Vous avez donc remarqué que certaines tâches étaient assez répétitives, et qu'il vous arrive régulièrement de réécrire des fonctionnalités très proches de ce que vous avez déjà codé auparavant. De plus, vous n'êtes jamais tout à fait sûr de la qualité de l'ensemble de votre programme :

avez vous omis certaines bonnes pratiques de sécurité ?
est ce que vos fonctions génériques sont elles vraiment optimisées ?
etc...

Et bien les frameworks ont été conçus pour cela : vous évitez d'avoir à réécrire des choses redondantes, et vous offrir un cadre de travail "pré-conçu" afin que vous puissiez vous concentrer sur le cœur de votre projet.

Prenons l'exemple d'une web agence qui développe de nombreux sites web tous les mois. L'équipe en charge du développement va devoir repartir de zéro pour chaque projet (chaque site est différent). En revanche, tous les projets se ressembleront fortement, à quelques exceptions près. Chaque site aura plusieurs pages, devra avoir un formulaire de contact, très certainement qu'il y aura des catégories, ou bien un "espace pro", etc...

Et bien avec un framework, on va s'éviter de devoir "ré-inventer la roue" à chaque fois. Le framework va nous donner tout un ensemble d'outils optimisés dans lesquels on va piocher afin de réaliser le projet dans les meilleures conditions.

Un autre avantage des frameworks, c'est la facilité avec laquelle on peux plonger dans un projet que l'on ne connait pas encore. Le framework offre une structure assez rigide, qui fait que, si un développeur connait bien un framework, il va pouvoir comprendre le code déjà écrit facilement, car l'architecture des projets sera la même malgré le fait que ce sont des projets différents.

Donc pour conclure, un framework est une boîte à outils pour développeur. Contrairement à un CMS (tel que Wordpress), un framework ne fait "rien" à priori, c'est à vous de coder l'intégralité de votre application, que ce soit un simple site web, ou un logiciel de gestion pour la banque de France. Comme son nom l'indique, un framework est un simple "cadre de travail", mais c'est une coquille vide. C'est à vous de coder ce dont vous avez besoin.

Un framework va donc vous fournir un ensemble de "briques logiciels" déjà codées, et une architecture pré-définies qui vont vous faire gagner en efficacité et en sécurité lors de vos projets de développement. Le revers de la médaille, c'est qu'il va falloir vous imprégner de la logique du framework, et explorer toute ces facettes avant d'être pleinement à l'aise dessus. Et ce temps d'apprentissage peux extrêmement varier d'un framework à l'autre : c'est ce qu'on appel la courbe d'apprentissage.

La courbe d'apprentissage est un critère déterminant lorsque l'on souhaite apprendre un nouveau framework, et celle-ci va évidemment dépendre de votre niveau initial et de votre implication.

~~ Just for fun ~~

Code Igniter : un framework PHP

CodeIgniter est un des frameworks PHP les plus populaires. Il tire sa popularité de sa légèreté, et de la facilité avec laquelle on peux le prendre en main. L'inconvénient, c'est qu'il offre moins de fonctionnalités qu'un framework plus complet tel que Symfony. Mais il convient tout à fait pour explorer et comprendre les grandes lignes d'un framework PHP implémentant le design pattern MVC (et pour faire des projets bien réels, bien entendu).

Comme je vous l'ai dit dans la section précédente, la courbe d'apprentissage d'un framework est un élément décisif dans le choix d'un framework, libre à vous par la suite d'apprendre de nouveaux frameworks. En France CodeIgniter est très concurrencé par Symfony, pour la simple est bonne raison que Symfony est un produit Français, et qu'il est donc un choix préféré par les entreprises. Il n'empêche que Symfony aussi à ses défauts, et il est souvent comparé à une usine à gaz.

Voici les parts de marché des principaux frameworks PHP en 2019, dans le monde :

Donc CodeIgniter est bien dans le top 3 des frameworks PHP, tout en étant facile à prendre en main pour des débutants. C'est donc par CodeIgniter que nous allons découvrir le concept de framework MVC.

CI existe depuis 2006, la version en cours est la 3 (3.1), mais la version 4 est quasiment prête à sortir au moment ou j'écris ces lignes. Nous apprendrons donc la version 3.1 de ce framework, qui est celle qui est la plus répandue à l'heure actuelle.

Pour conclure, vous devez savoir que CI a été initialement développé par la société EllisLab (fondée par Rick Ellis), qui a passé le relais au British Columbia Institute of Technology (université canadienne, semblable au MIT) sous une licence libre de droits (open source). C'est un framework qui est écrit en PHP, donc il n'y a aucun module particulier à installer pour le faire fonctionner (hormis l'environnement classique de PHP).

Rick Ellis, the boss

Rick Ellis : the boss

Le design pattern MVC

La grande majorité des frameworks PHP sont organisés autour d'une implémentation des design patterns Modèle / Vue / Contrôleur (on parle alors de MVC). Ce choix techniques s'est avéré trés adapté pour la réalisation d'applications web. Bien que remis en cause avec la popularisation des architecture d'API REST, il n'en reste pas moins une bonne solution pour certains projets (tout dépend de la nature du projet).

Mais c'est quoi le MVC ?

Le MVC consiste à scinder notre code en trois partie distinctes :

Le contrôleur : c'est la partie qui reçoit une requête provenant d'un client et qui va implémenter la logique "métier" de votre application. C'est donc une couche très importante, car c'est elle qui va abriter votre "logique".
Le modèle : c'est la partie qui va se charger de discuter avec votre base de données. Son rôle est cantonné à ça. Le contrôleur va requêter le modèle (via l'appel de méthodes sur un objet par exemple), et il va se charger de lui retourner un jeu de données correspondant.
La vue : c'est le document qui sera renvoyé à l'utilisateur (du HTML, mais potentiellement autre chose : JSON, XML, etc...).

Voici une illustration schématique du flux d'information dans un design pattern MVC :

Donc pour résumé :

contrôleur : réception des requêtes + logique métier + envoi des réponses
modèle : échange avec la base de données (SQL)
vue : stockage des templates de présentation des données destinés au client (HTML)

Dans CodeIgniter, les contrôleurs et les modèles sont des classes (POO), tandis que les vues sont de simples fichiers de templating PHP qui vont être chargés et personnalisés par le contrôleur afin de construire le document correspondant à une requête (bien souvent : une page HTML). Il vous faudra donc être assez à l'aise avec la programmation orientée objet pour bien vous servir de CI.

Vous comprendrez très vite l'organisation Modèle / Vue / Contrôleur à l'usage.

Attention : le MVC est une sorte de "bonne pratique" institutionnalisée, mais il ne tient qu'à vous de la respecter. Ce que je sous-entends par la, c'est qu'un framework vous laisse assez de liberté pour faire n'importe quoi si vous n'avez pas compris la place que dois avoir chaque partie de votre code au sein du framework. Le framework vous offre une architecture optimisée et prête à l'emploi, à vous de l'utiliser au mieux. Comme dans tous programme, le développeur dispose d'assez de liberté pour optimiser son code, mais aussi pour faire des bêtises... Donc à vous de bien vous imprégner de cette philosophie afin de l'appliquer correctement pour ne pas "gripper" la machine.

Installation

Pour installer CI, c'est très simple. Il vous suffit de télécharger l'archive sur le site officiel, puis de l'extraire dans votre dossier de projets web. Une fois que c'est fait, vous n'avez qu'à ouvrir l'URL correspondat au dossier, et le fichier index.php vous affichera quelque chose comme ceci :

Pour l'instant, CI est bien installé, et ceci est votre "page d'accueil".

Un texte explicatif vous explique ou se trouve les fichiers à modifier si vous souhaitez changer le comportement de la page d'accueil.

Architecture de CodeIgniter

Racine du dossier

La racine est composée de 2 dossier imortant, et de quelques fichiers plus ou moins important :

le dossier "system" : c'est le cœur de CI. C'est dans ce dossier que sont stockés toutes les librairies, classes, scripts, etc... que vous utiliserez pour développer votre application. Théoriquement, vous n'avez pas à modifier sont contenu. Une modification dans ce dossier peux très vite "tout casser", et si vous souhaitez mettre à jour CI, tout ce que vous aurez écrit la dedans sera perdu. Il existe en revanche des techniques pour surcharger les comportements standards de CI, sans avoir à modifier le contenu du dossier "system". Nous verrons ça plus tard.
le dossier "application" : c'est dans ce dossier que vous allez écrire la majorité du code que nécessite votre application. En plus du système de MVC, il contient de nombreuses choses qui vous permettront de développer votre logiciel.
le fichier "index.php" : c'est le point d'entrée de votre application. Toutes les requêtes qui arriveront sur votre site passeront par ce fichier afin d'être traitées par le framework.

Le dossier "system"

Comme vu au point précédent, le dossier "system" est le cœur de CI. Allez jeter un œil à l'intérieur, dans les différents dossier.

Dossier "core" :

la configuration
gestion du MVC (Model, Controller)
le routeur
etc...

Dossier "librairies" :

validation de formulaire
gestion des images
email
etc...

Dossier "helpers" :

internationalisation
utilisation du système de fichier (dossier / fichier)
gestion des url du site
etc...

Tout ça, ce sont les outils de base qu'offre CI. Ils vont vous permettre de faire tout un tas de choses sans avoir à les coder vous même. Et c'est plutôt une bonne chose, car en plus de vous faire gagner beaucoup de temps, ces outils sont très optimisés et sécurisés, ce qui va vous permettre d'avoir un code certainement plus propre que ce que vous auriez codé vous même.

Le dossier "application"

Voici votre coquille vide ! C'est dans ce dossier que vous allez écrire le code nécessaire à votre application. Comme on peux le voir sur l'image, il y a déjà les fichiers :

Welcome.php dans le dossier controllers (c'est votre contrôleur de bienvenue, afin de vérifier que tout fonctionne correctement)
welcome_messsage.php dans le dossier views (c'est votre vue de bienvenue)

Présentation des différents dossiers :

controllers/models/views : ce sont les dossiers qui hébergeront vos fichiers de modèles, vues, controlleurs
config : c'est la que vous allez modifier la configuration de votre application (par exemple : les routes, mais aussi vos variables d’environnement dev/test/prod, comportement de base, format de date, etc...). Chaque fichier du dossier config regroupe un ensemble de configurations homogène (database, autloading, config générale, etc...)
core/helpers/libraries : c'est ici que vous allez créer vos propres helpers ou librairies, mais aussi que vous allez pouvoir surcharger celles déjà existantes afin qu'elles fassent exactement ce que vous souhaitez
les autres dossiers sont moins utilisés, mais correspondent tous à un besoin bien précis. Par exemple si votre site doit gérer plusieurs langues, ce sera dans le dossier "language" que ça se passera

Routage

Le routage dans CI est assez simple a utilisé. Il se gère principalement dans le fichier routes.php dans le dossier /config.

Routage automatique

Il existe un mode "par défaut", ou le choix du contrôleur, de la méthode et des paramètres se fait directement en fonction de ce qu'il y a dans l'URL.

Par exemple :

URL => /product/display/1

controlleur : Product
méthode : display
paramètre : 1

Routage dynamique :

On peux aussi créer des routes manuellement, et les faire pointer vers un contrôleur. Dans le fichier config/routes.php, il vous suffira de renseigner un tableau associatif PHP, ou la clé représente la route, et la valeur le controlleur méthode.

Par exemple :

$route['product/(:num)'] = 'ProductController/displayProduct/$1'

Ceci fera pointer l'URL /product/3 vers la méthode ProductController/displayProduct/3

Routage avancé :

CI nous laisse assez de liberté pour implémenter le système de route que l'on souhaite. Personnellement, j'avais écrit une librairie qui construisait les routes en fonction de certaines données présentent dans la BDD.

Voici le lien vers la doc officielle pour le routage dans Code Igniter : https://codeigniter.com/userguide3/general/routing.html?highlight=route

Contrôleur

Maintenant que nous avons vu l'architecture standard de CI, nous allons créer notre premier contrôleur.

Mise en place du contrôleur

Dans votre dossier application/controllers, créez un nouveau fichier Test.php, sur la même base que Welcome.php. Une fois que c'est fait, renommez la classe Welcome, en classe Test. Puis dans la méthode index du fichier Test.php affichez "Je suis dans mon contrôleur test".

Une fois que c'est fait, charger l'URL index.php/test

Si tout se passe bien, votre navigateur affichera le message "Je suis dans mon contrôleur test".

Vous remarquerez que l'URL n'est pas très propre (/index.php/test). Notre but est de pouvoir accéder à notre page /test via l'URL /test. Pour ce faire, nous allons commencer par activer la réécriture d'URL via un fichier .htaccess (fonctionne pour Apache, si vous utilisez Nginx, ce sera via une autre technique).

Créez tout d'abord un fichier .htaccess à la racine de votre projet, puis collez ceci à l'intérieur

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

Source : https://gist.github.com/keithmorris/3023560

Ces directives Apache vous permettent d'avoir des URL plus propres. Elles vont rediriger toutes les URL vers index.php, en lui passant le reste de l'URL en paramètre. Donc l'URL /test deviendra pour apache /index.php/test, c'est exactement ce que nous recherchons à avoir. Vous pouvez à présent appelez la route /test, celle-ci pointera vers votre contrôleur Test.php, et vous retrouvez votre affichage "Je suis dans mon contrôleur test".

Les méthodes

A présent, nous allons créer une deuxième méthode à notre contrôleur Test. La méthode index étant la méthode par défaut, nous allons créer une méthode personnalisée :

dans votre contrôleur Test, rajouter une méthode intelligence
dans la méthode intelligence, affichez la phrase "Bienvenue dans le test de QI"
appelez l'URL /test/intelligence

Et voila, votre application affichera "Bienvenue dans le test de QI" quand on appellera l'URL /test/intelligence

Les paramètres

A présent, nous allons rajouter un paramètre à notre méthode intelligence. Rajoutez le paramètre age avec zéro comme valeur par défaut à votre méthode intelligence. Une fois que c'est fait, rajouter une ligne de texte à la suite de votre méthode qui affichera "Ok, vous avez $age ans". Puis rechargez la page /test/intelligence. Comme vous pouvez le constater, la page doit afficher ceci :

Maintenant, changez l'URL en /test/intelligence/30. Vous devriez avoir ceci :

Et voila, vous venez de découvrir le principe du contrôleur dans un framework MVC. Voici un schéma récapitulatif :

Voici un lien vers la page concernant les contrôleurs dans la doc officielle.

Utiliser les fonctionnalités de CI

Quand vous écrivez du code dans vos méthodes de contrôleur, vous êtes en POO. Donc vous manipulerez souvent la variable $this. Dans CI, on peut appeler tout un tas de choses directement via l'objet courant $this, qui hérite du contrôleur principal de CI.

Vous allez pouvoir charger des éléments du framework :

vos modèles
vos vues
des librairies
des helpers
etc...

Mais vous allez aussi pouvoir surcharger le contrôleur principal selon vos besoins :

créer des attributs de classes
utiliser des méthodes interne à votre contrôleur
surcharger le contrôleur principal avec de nouvelles méthodes personnalisées
etc...

Attention : si vous souhaitez utiliser des fonctionnalités du framework en dehors d'un contrôleur (par exemple dans des classes utilisateur), il vous faudra passer par la fonction globale get_instance(). Cette fonction vous renverra le singleton de CI en cours. Vous pourrez alors utiliser CI, même à l'extérieur d'un contrôleur. Cela est très utile dans de nombreux cas.

Voici un exemple dans une entité métier :

$this->CI = &get_instance();
$this->CI->load->model('customisation_model', 'custom'); /*La méthode load ne serait pas accessible sans récupérer l'instance de CI*/

Note : le "&" représente le passage d'une variable en référence. Cela veux dire que l'on ne copie pas la valeur de la variable, mais qu'on pointe directement vers son emplacement en mémoire. C'est une notion importante à connaitre, si vous ne la connaissez pas, je vous encourage à voir comment ça marche et à quoi ça sert. Lien vers la doc officielle : https://www.php.net/manual/fr/language.references.whatare.php

Charger des vues

Maintenant que nous avons vu comment fonctionne le contrôleur, voyons comment fonctionne la vue. L'idée est simple : on va utiliser la méthode load de l'objet "global" (qui est disponible dans les contrôleurs via l'utilisation de la variable $this), puis lui demander de charger une vue en lui donnant le nom de la vue désirée :

$this->load->view('le_nom_de_ma_vue');

Le nom de la vue correspond au nom du fichier, sans l'extension.

Chargement d'une vue

dans votre dossier views, créer un nouveau fichier qi.php
dans votre fichier qi.php, écrivez un peu de HTML du type "Ceci est la vue de mon test de QI"
dans votre méthode intelligence, si tout les paramètres sont renseignés, chargez la vue qi.php grâce à cette syntaxe : $this->load->view('qi')

Si tout se passe bien, voici ce que vous devriez avoir :

A ce stade, nous avons simplement chargé un fichier PHP correspondant à la réponse retournée au client, c'est notre document HTML. Mais pour l'instant, le document HTML contient un simple texte, il ne prends pas en compte les variables age et prenom. Voyons voir comment passer des données à la vue qi.php.

Envoyer des données à la vue

dans votre méthode intelligence, avant de charger votre vue, créer une variable $data contenant un tableau vide
dans ce tableau $data, créez une clé age qui contient la valeur de $age et une clé prenom qui contient la valeur de $prenom
passer le tableau $data en deuxième paramètre de la méthode vous permettant de charger la vue
dans votre fichier qi.php, faites un peu de HTML pour incorporer les variables $prenom et $age

Rappelez votre méthode intelligence via l'URL avec l'âge et le prénom que vous souhaitez.

Vous devriez obtenir quelque chose comme ceci :

Voici un lien vers la page concernant les vues dans la doc officielle.

Modèle

Créer un modèle

Le modèle est la partie qui va se charger des données "brutes", il abrite très peu de logique, et pas du tout d'affichage. Dans CI, pour créer un nouveau modèle de données (modèle), il suffit de créer un fichier dans le dossier models, de respecter la syntaxe Nomdumodel_model.php, et de créer une classe qui porte le même nom que le fichier, et qui étends de la classe native CI_Model.

Reportez vous à la doc officielle si besoin. Les fichiers et le noms des modèles doivent commencer par une majuscule (comme les contrôleurs). Ce sont les conventions obligatoires de CI, qu'il faut respecter sinon le framework n'arrive pas à trouver les bons fichiers.

Charger un modèle

Pour charger un modèle dans un contrôleur, il suffit d'utiliser cette méthode :

$this->load->model('nom_du_model');

Utiliser un modèle

On va continuer nos tests sur l'exercice du test de QI :

créer un nouveau modèle test, qui contiendra nos jeux de question/réponse
dans le modèle test, créer une méthode enfant qui retourne ce tableau :

[
 "Quelle est la somme de 3 + 5 ?" => "8",
 "Quelle est la capitale de l'Allemagne ?" => "Berlin",
 "Quelle lettre se trouve à la suite de 'A / E / I / O' ?" => "U"
]

chargez le modèle test dans votre méthode intelligence
dans la méthode intelligence appelez la méthode enfant du modèle test afin de récupérer le jeu de question/réponse
stockez le résultat dans la variable $data
envoyez la variable $data à votre vue enfant
dans la vue enfant, affichez le jeu de question/reponse sous forme de liste HTML

Voici ce que vous devriez obtenir sur l'URL /test/intelligence/5/pierre :

Renommer le modèle lors du chargement

Comme vous l'avez remarqué, l'objet modèle deviens accessible dans la variable globale $this. En revanche, on y accède en saisissant le nom complet du modèle, ce qui peut être embêtant à taper régulièrement. Voici comment on peux renommer le modèle dans l'objet $this :

$this->load->model('test_model', 'test');

A ce moment la, vous pourrez accéder à votre objet test en saisissant simplement :

$this->test->nom_de_la_methode();

Pratique ! C'est une des nombreuses possibilités de personnalisation qu'offre CI, vous les découvrirez au fur et à mesure.

Voici un lien concernant les modèles dans la doc officielle.

Base de données

Maintenant que nous savons comment fonctionne le modèle, on va rajouter la notion de base de données à notre exercice. Pour ce faire, commencer par créer une nouvelle base de données dans votre environnement, et récupérez toutes les informations d'authentification habituelles (nom, password, hôte, etc...).

Configurer les données d'authentification à la base de données

Une fois que c'est fait, il va falloir configurer la partie "base de données" de CI pour qu'il puisse se connecter à votre base de données. Rendez vous dans le fichier database.php du dossier config, puis renseignez les informations d'authentification standard (hostname, user, password, database) :

Une fois que c'est fait, créez une table test dans la base de données, avec les champs suivants :

id (auto-increment)
type (enfant/ado/adulte)
question (text)
reponse (text)

Supprimez les question/réponse du modèle et insérez les manuellement dans la base de données.

Pour accéder à la base de données CI propose une librairies très complète qui va vous permettre de construire vos requêtes de différentes manières.

Charger la librairie Database

Une des principales librairies de CI, c'est celle qui permet de travailler avec la base de données. Au même titre que les modèles et les vues, pour pouvoir utiliser une librairies dans votre code, il faut avant tout la charger. De cette manière, votre code charge seulement ce qu'il a besoin au moment ou il en a besoin.

On verra d'autre mode de chargement plus tard, mais pour l'instant :

videz complètement le contenu de la méthode enfant du modèle
dans cette méthode, charger la bibliothèque database grâce à cette instruction $this->load->database()

Pour l'instant, la librairie database est disponible dans la méthode enfant. C'est tout. Cette méthode va lire la configuration que vous avez saisi dans le fichier conf/database.php, va s'en servir pour se connecter à la base de données et va vous permettre d'exécuter des requêtes via la propriété db de l'objet $this. On aura donc accès aux méthodes de la libraire database de cette manière :

$this->db->la_methode_que_je_souhaite_utiliser()

Info : vous pouvez aussi avoir besoin de travailler avec plusieurs bases de données dans certains projets. Il vous suffira alors de définir plusieurs configuration dans le ficher database.php, puis de charger celle que vous souhaitez de cette manière :

$this->load->database('autre_base_de_données');

La configuration par défaut se nomme default.

Exécuter une simple requête SQL

Maintenant que vous êtes connecté à votr base de données, et que l'objet global $this comporte un objet db, vous allez avoir accès à toutes les méthods de ravail avec la base de données, un peu comme PDO. La méthode la plus ismple pour exécuter une requête SQL est la méthode query de la classe db. Ca donnera quelque chose comme cela :

$query = $this->db->query("VOTRE requête SQL");

Cette requête vous renvoi une ressource, et non pas directement les données. Au même titre qu'un fetch PDO, il va falloir utiliser une méthode intermédiaire pour récupérer toutes les lignes une par une, de cette manière :

foreach ($query->result() as $row) {
  $id = $row->id;
}

CodeIgniter offre quelques méthodes simple dans ce style, assez proche de PDO, telles que :

simple_query : exécute une requête sans retourner de résultats (insert, update, etc...)
gestion des préfixes : pour ne pas avoir à écrire de préfixes de tables redondants
échappement des variables émanant de l'utilisateur : comme la méthode quote de PDO
etc...

Voici un lien vers la documentation officielle concernant les méthodes de requêtes simple de CI.

Aussi, au même titre que PDO, il y a différents style de retours possible. Nous avons vu result(), mais il y en a d'autres :

result_array()
row()
row_array()
etc...

Voici un lien vers la doc officielle concernant la récupération des résultats d'une requête.

Query Builder

CI vous offre une deuxième manière de préparer et d’exécuter vos requêtes SQL. Le Query Builder est une classe à part, en plus de la classe Database, qui va vous permettre de construire des requêtes SQL en écrivant le moins possible de SQL. Vous allez pouvoir "coder" la construction de votre requête, et donc construire une requête de manière plus souple, et plus sécurisée qu'en écrivant votre requête SQL à la main.

Pour faire simple, la classe Query Builder regroupe de nombreuses méthodes qui correspondent peu ou prou à l'ensemble des mots clés principaux qu'utilise le langage SQL. Vous trouverez donc des méthodes qui ont le même nom que les mots clés suivant :

SELECT : méthode select()
FROM : méthode from()
WHERE : méthode where()
etc...

Vous trouverez aussi des expressions plus avancées :

WHERE aaa = 'bbb' OR ccc = 'ddd' : methode or_where()
WHERE aaa IN ('bbb', 'ccc') : méthode where_in()
etc...

Bref, il y a de nombreuses méthodes que vous pourrez exploiter. De plus, ces méthodes sont assez souples pour prendre en charge différents paramétrages. Par exemple, au lieu d'appeler plusieurs fois la méthode where() afin d'appliquer plusieurs WHERE dans votre requête SQL, vous pouvez envoyez un tableau en argument.

Exemple :

$user = array('nom' => $nom, 'prenom' => $prenom, 'naissance' => $date);
$this->db->where($user);

produira

WHERE nom = 'Dupont' AND prenom = 'Pierre' AND naissance = '1990-05-01'

Ceci est très utile lorsque vous allez construire des requêtes dynamiquement dans votre code. Et cela vous permet de vous concentrer uniquement sur les données variables de la requêtes, et non sur la syntaxe SQL.

Il y a vraiment beaucoup de méthodes disponibles, et de manières de les utiliser. Je vous invite donc à vous familiariser avec la doc officielle du Query Builder de CI.

Important : n'oubliez pas, cette classe ne vous permet que de construire une requête, il vous faudra ensuite exploiter la ressource retournée par le SGBDR avec les méthodes vues précédemment (result(), result_array(), etc....).

Dossier public

Pour l'instant, notre site ne comporte aucun fichier "publique" (javascript, css, images, etc...). On va donc mettre en place ce dossier, et y placer quelques images que nous appellerons dans nos trois vues :

créer un dossier assets à la racine de votre projet
créez un dossier img dans votre dossier assets
téléchargez une image d'enfants, une image d'ado, et une image d'adulte
insérez les images dans chaque vue correspondante afin que la vue enfant ait une image d'enfant, ado => ado, et adulte => adulte

Note importante : les URLs correspondantes à l'appel des images seront de cette forme :

/assets/img/enfant.jpg

Hors, comme nous l'avons configurer dans le .htacess, toutes les URLs sont sensées être redirigées vers la page index.php, et envoyées vers le contrôleur correspondant. Sauf que nous n'avons pas de contrôleur assets dans notre dossier controllers. Ceci est normal, car les directives du fichiers .htaccess ne redirigent pas les appels correspondants à des fichiers ou des dossier.

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

Configuration

La configuration de votre application se fait dans le dossier config de CI. Ce dossier contient tout une série de fichier pour configurer les différents aspects de votre application :

config.php : config de base (url, langue, encodage, etc...)
autoload.php : qui permet de charger automatiquement certaines choses (ex : un modèle en particulier, lib database, lib session, helper url, etc...). Ce qui vous permet de ne pas avoir à le faire manuellement dans vos contrôleurs. Les entités chargées dans autoload sont automatiquement disponible dans vos contrôleurs.
database.php : permet de fournir les identifiants de connexions aux DBs + quelques réglages. CI permet de travailler sur plusieurs DB (dans le même environnement) très facilement
email.php : config de la connexion au serveur d'email.
routes.php : pour gérer les routes

Tous ces fichiers sont chargés automatiquement par CI lorsque votre programme s'exécute, et avant l'appel de votre controleur.

Exemple de config dans autoload.php :

Ici, CodeIgniter chargera automatiquement les librairies database et session, et les helpers url, form et array.

Changer la conf en fonction de l'environnement

Vous pouvez changer votre conf en fonction de l'environnement dev/test/prod en utilisant ce type de mécanisme :

Avec cette architecture, CodeIgniter ira chercher en priorité les fichiers présents dans le dossier correspondant à l'environnement en cours (dev/test/prod, défini dans index.php). Cela vous permet de définir des variables différentes en fonctions de votre environnement, tout en en gardant certaines communes à tous. Si CodeIgniter ne trouve pas le bon fichier dans le dossier d'env, il prendra celui qui est présent dans le dossier conf.

Ajouter des configurations supplémentaires

Vous pouvez rajouter des configurations sur certaines librairies, mais qui n'ont pas de configurations standard. Par exemple, avec la librairie form_validation, vous pouvez configurer l'ensemble de vos règles de validations de formulaire dans un seul fichier de conf :

Librairies

Au même titre que le routeur, les librairies ne font pas à proprement parler parties du design pattern MVC. Ce sont des outils supplémentaires fournis par le framework, mais qui s'intègrent correctement à la façon de faire de CodeIgniter. Vous allez donc pouvoir les utiliser facilement, et faire un travail énorme, en seulement quelques lignes de code.

CodeIgniter mets à disposition toute une série de librairies que vous pouvez utiliser dans votre application. Vous pouvez ouvrir le dossier system/libraries pour en voir la liste.

En voici quelques-unes pour l'exemple :

gestion des emails
validation de formulaires
manipulation d'images
gestion des migrations
génération de pagination
gestion de l'upload
etc...

Ces librairies vous seront très utiles car elles vous permettent de bénéficier de fonctionnalités très communes à toutes les applications, sans avoir à les coder vous-même, ou à utiliser les classes natives de PHP, parfois un peu longues à prendre en main. Vous pouvez charger vos librairies de deux façons.

Via l'autoloading de CI

Cette méthode permet de charger des librairies qui seront disponibles partout, sans que l'on ai besoin de les appeler manuellement.

Rendez-vous dans le fichier application/config/autoload.php

Puis, si vous souhaitez activer la librairie database et session partout dans votre application, vous devez rentrer ce genre de configuration :

$autoload['libraries'] = array('database', 'session');

Ensuite, vous pourrez utiliser la DB (dans vos modèle par exemple) de cette manière :

$this->db->select('image')->from($this->table)->where('id', $id)->get()->row(); /* Ici, la propriété db de l'objet courant est ajoutée automatiquement via l'autoloading de CI */

À la volée, directement dans vos contrôleurs

Dans le cas ou vous avez besoin d'une librairie uniquement à certains endroits de votre application, vous avez la possibilité de les charger à la volée, selon les besoins.

Exemple avec la librairie de gestion des images :

$config['image_library'] = 'gd2'; /* Paramétrage de la config de la librairies*/
$config['source_image'] = '/path/to/image/mypic.jpg';
$config['create_thumb'] = TRUE;
$config['maintain_ratio'] = TRUE;
$config['width'] = 75;
$config['height'] = 50;

$this->load->library('image_lib', $config); /* chargement de la lib, avec la config voulu*/

$this->image_lib->resize(); /*Exemple : redimenssionnement d'une image en 75*50 */

Voici le lien vers la doc officielle de la librairies de gestion des images : https://codeigniter.com/userguide3/libraries/image_lib.html

Il y a de nombreuses librairies, donc nous ne les verront pas toutes en détails, mais garder en tête cette approche :

configuration de la librairie selon vos besoin
chargement de la librairies (via autoload ou appel manuel)(ne pas oublier de lui donner la conf si nécessaire)
utilisation des méthodes de la dite librairie

Pour finir, regardons la doc des deux librairies suivantes :

pagination : https://codeigniter.com/userguide3/libraries/pagination.html
validation de formulaire : https://codeigniter.com/userguide3/libraries/form_validation.html

Helpers

Les helpers sont comme des librairies, mais généralement plus légèrs, et écrits en procédurale. Elles vous permettent de bénéficier de quelques fonctionnalités simples, mais utiles, en plus des "grosses" librairies.

Les helpers sont des séries de fonctions traitant du même thème. Il suffira alors de charger le helper en question, puis d'appeler telle ou telle fonction suivant les besoins de votre application. L'avantage des helpers, c'est qu'ils peuvent être appelé directement à l'intérieur de vos templates de vues, contrairement aux librairies qui nécessitent l'environnement "objet" de CI.

Voici quelques helpers utiles :

url : permet de générer différents types d'url selon la conf de votre application => https://codeigniter.com/userguide3/helpers/url_helper.html
text : permet de faire des traitements sur les chaînes de caractères ou du texte. Certaines fonctions sont bien sympas, telles que la censure ou la mise en lumière de certains termes... => https://codeigniter.com/userguide3/helpers/text_helper.html
form : offre tout un panel de fonctions concernant les formulaires : génération des champs, affichage automatique des erreurs de validations, remplissage ou sélection automatique de certains champs, etc... => https://codeigniter.com/userguide3/helpers/form_helper.html
et bien d'autres encore !

Vous les retrouverez tous dans le dossier system/helpers de CodeIgniter:

Vous pouvez charger vos fichiers de helpers de la même manière que les librairies :

en autoload, si vous l'utilisez très souvent dans votre application
manuellement, si vous avez un besoin ponctuel

Voici un exemple de chargement manuel du helper "url" :

$this->load->helper('url'); /* Charge le helper url dans le contrôleur*/

Une fois le helper chargé, vous pouvez utiliser une des fonctions qu'il propose dans vos vues par exemple. Le helper url propose une fonction base_url(), qui vous renvoie l'URL de base de votre application. Plus besoin de plonger dans la conf, le helper le fait pour vous.

Donc vous pourrez très bien écrire ceci :

echo base_url(); /* Affichera ce qui est en conf*/

Voici le lien vers la page de présentation des helpers de CodeIgniter : https://codeigniter.com/userguide3/general/helpers.html

Layout

CodeIgniter3 ne propose pas de librairies de Layout par défaut, il faut gérer ça comme une librairie personnelle, ou bien trouver quelque chose sur Internet qui fasse le job.

Note : pour ceux qui ne savent pas encore ce qu'est un layout, nous en parlerons rapidement à l'oral. En gros, c'est "la partie fixe" de votre interface, celle qui ne bouge quasiment pas entre chacune des pages composant votre application.

Je vous conseille de créer la vôtre, afin de comprendre comment créer et utiliser vos propres librairies.

Voici 2 liens pour vous mettre sur la piste :

le tuto openclassroom de CI3. Vieillissant, mais pas mal pour débuter => https://openclassrooms.com/fr/courses/82136-codeigniter-le-framework-au-service-des-zeros/82134-mise-en-place-des-themes
un repo Github dédié pour une librairie de layout : https://github.com/vmoulin78/codeigniter-layout-library/blob/master/application/libraries/Layout.php

Profiler

Le profiler est un outils inclut dans CodeIgniter qui vous permet d'afficher de nombreuses informations techniques concernant la page en cours, telles que :

les données de GET/POST (input)
le temps d'exécution
les requêtes SQL exécutées
les headers HTTP
etc etc...

Il s'active facilement via ces lignes de codes :

$this->load->library('profiler');
$this->profiler->run();

Et il affichera ce genre d'informations :

Comme toutes les autres librairies de CI, vous pouvez la surcharger afin d'afficher des informations complémentaires. Par exemple : afficher toutes les routes disponibles, etc...

Voici un lien vers la doc officielle : https://codeigniter.com/userguide3/general/profiling.html

Surcharge des classes système

CodeIgniter vous permet de facilement surcharger les classes système, les librairies et helpers. Pour cela, il vous suffit de respecter les conventions de nommage de vos fichiers, et de les placer dans les bons dossiers. Automatiquement, CodeIgniter chargera vos classes personnalisées en enfant des classes systemes.

Voici un exemple avec le contrôleur et le modèle :

Dans cet exemple, on surcharge le modèle et le contrôleur de base de CI. Du coup, tous nos contrôleurs et modèles hériteront automatiquement des méthodes que nous aurons écrites dans les surcharge. Pratique.

Choses à respecter :

placer les fichiers dans le dossier application/core
respecter la convention de nommage du fichier avec le préfixe MY_
étendre la classe désirée (ex : CI_XXX) avec une classe personnalisée MY_XXX

On peut aussi, et de la même manière, étendre une librairie. Exemple avec la librairie "image" :

Ici, la méthode crop_image() est une méthode personnalisée pour les besoins de l'application. Elle sera disponible, en plus de toutes les autres méthodes déjà proposées par la librairie, lorsque l'on chargera la librairie "image".

Ce mode de fonctionnement est très pratique, car il vous permet de redéfinir des classes systèmes, sans prendre le risque de tout perdre lorsque vous mettrez à jour la version du framework. Un peu comme les thèmes enfants de Wordpress, pour ceux qui connaissent.

Internationalisation

Avec CI, vous bénéficiez d'une internationalisation déjà existante sur toutes les librairies standard. Cela veux dire que les messages destinés à l'utilisateur sont traités dans un fichier à part, qui est automatiquement appelé lorsque la librairie doit renvoyer des erreurs, ou divers message. Par défaut, la langue est l'anglais, mais vous pouvez trouver des traductions toute faites en français, ou bien faire vos propres traduction au besoin, c'est très facile (si on comprend l'anglais un minimum).

Prenons exemple sur la librairie "form_validation". Comme vous le savez déjà, la validation de formulaire est souvent très verbeuse en termes de messages destinés aux utilisateurs :

un mot de passe ne correspond pas au conditions de sécurité requise par l'application
une donnée est erronée (par exemple : mauvaise saisie d'un e-mail)
un champ est laissé vide alors qu'il doit obligatoirement être rempli
etc...

Je ne vous fais pas toute la liste des cas de figure tellement on pourrait en trouver des différents...

Lorsque l'on code ce genre de chose, on se retrouve avec beaucoup de message "en français", calés à l'intérieur de notre programme. Ce qui n'est pas confortable du tout le jour ou votre entreprise va vouloir s'étendre sur un marché non-francophone (ex : anglais, espagnol, allemand). Il faut donc prévoir en amont un système qui permet de changer la langue des messages destinés à vos utilisateurs facilement, via une simple variable de type :

$lang = 'fr'; /* Le logiciel répondra en francais*/
$lang = 'en'; /* Le logiciel répondra en anglais*/
$lang = 'de'; /* Le logiciel répondra en allemand*/

Concrétisation dans CodeIgniter

Pour utiliser l'internationalisation dans CI, voici comment procéder.

1 - Paramétrer la bonne langue dans le fichier de config application/config/config.php :

2 - Rendre disponible les fichiers de traduction dans votre application :

=> Soit en copiant/collant le dossier "anglais" (et le renommer en "french"), puis en faisant les traductions au fur et à mesure. Soit en trouvant un fichier français déjà traduit.

Avec ce système, a chaque fois que la libraire de validation de formulaire détectera des erreurs dans les données saisies, elle ira chercher les messages d'erreur directement dans les fichiers d'internationalisation.

Note : les messages prennent deux valeurs variables possibles, field et param, qui correspondent au nom du champ et à un possible paramètre existant dans la fonction de validation. Par exemple la ligne form_validation_max_length sera réécrite de cette manière : "Le champ pseudo doit contenir au moins 6 caractères".

Code Igniter 4

https://codeigniter.com/

A voir :

SEEDER
MIGRATION
FAIRE TOUTES LES BONNES PRATIQUES
API
CLI
ENTITIES
LIB : kint, faker
ENV
TESTING
CLI

Travaux pratique

Afin de s'entrainer sur CodeIgniter3, je vous propose de réaliser un CMS de gestion de carte de restaurant. L'idée est simple : permettre au restaurateur/café/bar de proposer une carte en ligne à leur client. Bref, remplacer la carte "à l'ancienne" par une version numérique. Vous pouvez bien évidemment réaliser cette application de nombreuses manière (framework, from scratch, API, etc...), mais la démo que vous allez voir a été réalisé avec CodeIgniter 3, et sans API. Je vous demande donc d'utiliser à minima un framework MVC (Symfony, Laravel, etc...) de votre choix.

C'est parti !

Donc l'application se décompose en deux parties importantes :

un back-office pour que les restaurateurs puissent gérer leur carte (ajouter des produits, modifier des images, etc...)
un front-office, dédié aux clients de l'établissement (visualisation de la carte, etc...)

Le front-office est plutôt pensé pour les smartphones à la base, mais vous pouvez réaliser une interface full responsive.

Vous trouverez le résultat final à atteindre en ligne, à cette URL : http://smartmenu.fr. J'ai réalisé cette application il y a maintenant quelques années, donc tout n'est peut-être pas tout à fait a jour. Mais cela fonctionne bien, et vous servira de guide pour développer votre version. Donc n'essayez pas de faire exactement la même chose, mais plutôt de vous en inspirer.

Voici quelques fonctionnalités à coder en priorité, qui sont vraiment importantes. Pour ceux qui seront notés sur ce TP, vous devez réaliser toutes ces fonctionnalités en priorité :

pouvoir créer un nouvel établissement (en respectant les bonnes pratiques de sécurité)
pouvoir modifier les informations de base de l'établissement (nom, url, adresse, etc..)
créer/modifier/supprimer des catégories pour la carte (entrées, plats, desserts, ...)
créer/modifier/supprimer des produits dans chaque catégories
afficher la carte en front-office, pour que les clients puissent y accéder

Les autres fonctionnalités que vous pourrez voir dans la vidéo de présentation sont optionnelles, mais vous aideront à gagner des points si vous les réalisez.

N'oubliez pas d'inclure le maximum de bonne pratique dans la conception de votre application, telles que :

respect du MVC
routes propres
utilisation des différentes librairies et helper offert par le framework
conception de base de données propre
respect des normes de sécurité
front-end propre (vous pouvez utiliser un framework), et un minimum agréable à l'oeil
etc...

Vous avez toute la liberté d'implémenter les technos qui vous semblent adaptées (framework JS, framework CSS, ORM, tests, migration, etc...), mais n'oubliez pas que vous allez réaliser cette application dans un temps impartis, donc privilégiez des outils simples et rapide à mettre en œuvre.

Une image vaut 1000 mots, une vidéo en vaut 10000, donc place à la présentation vidéo de ce que vous devez réaliser.

Liens utiles

Non disponible

Exercices