Avant de commencer un petit tutoriel sur Jelix, je crois bon de commencer par vous le présenter afin d’avoir les idées un peu plus clair avant de débuter tout développement avec ce dernier.

Jelix est un framework initié par un français Laurent Jouanneau qui a l’origine si je ne dis pas de bêtise avait bossé sur Copix.

Cette article va présenter plus en détails les différents API de Jelix et permettre par la suite d’aborder plus sereinement un petit tutoriel.

Fonctionnement

Jelix est, comme la grande majorité des framework, basé sur le design pattern MVC afin d’avoir une séparation logique du code de notre site.
Le modèle est une classe donné qui va interagir avec la base de données (récupération de données, etc…). La vue est ce que l’utilisateur va obtenir au final (un flux RSS, une page HTML, un fichier XUL) avec les données qu’on obtenu préalablement avec le modèle. La vue est dans Jelix assuré par des templates dont la syntaxe est proche de Smarty.
Quand au contrôleur, il est le chef d’orchestre, il va se charger de mettre les données en relation avec la vue pour générer au final une sortie vers l’utilisateur.
Jelix intègre une sécurité supplémentaire qui permet de “typer” la vue et d’être sûr du format de sortie.
En effet, Jelix permet via des objets Responses de générer à partir d’un même modèle un flux RSS, une page HTML, des données JSON, etc…

Mécanisme des Urls

Jelix utilise un point d’entrée pour appeler les différents modules et les actions associés. Pour ce faire, Jelix se sert de la syntaxe suivante :

Ces urls peuvent être réécrite soit à l’aide de mod_rewrite soit à l’aide de Jelix (voir ci-dessous).

Structure du projet

Sur la figure ci-dessus, on peut voir trois dossiers racines :

• lib : C’est l’ensemble des librairies de Jelix
• temp : c’est le dossier de cache de votre application
• jactu : C’est le dossier de votre application (que vous pouvez appeler comme vous voulez) qui est scindé en plusieurs sous-dossiers : 
• les modules (répertoire demo par exemple), permet de séparer les différentes fonctionnalités de votre site (par exemple, un module forum, recherche, profil). Ce découpage facilite la réutilisation de code. Chaque module comporte les dossiers suivants :
• les classes (dossier classes) : contient les classes métiers et autres objets. Les fichiers doivent suivre la nomenclature suivante monfichier.class.php
• les contrôleurs (dossier controllers)
• les daos (dossier daos)
• les formulaires (dossier forms)
• les locales (dossier locales)
• les templates (dossier templates)
• les zones (dossier zones)
• les plugins (répertoire plugins) :
• la configuration (répertoire var) : la configuration est simple à éditer, ce sont des fichiers ini qui vont permettre de personnaliser les différentes options du framework (la langue par défaut, les paramètres d’accès à la base de données). Ce répertoire contient également les fichiers de log que vous pouvez créer ou utiliser le fichier par défaut.
• le point d’entrée (répertoire www) : c’est ici que les visiteurs atterrissent, ils n’ont pas accès aux autres ressources directement.

Les API

Jelix propose des API qui peuvent vous aider à résoudre les problèmes que vous pouvez rencontrer dans vos développements quotidiens.
Certains de ses API sont facultatives et libre à vous de les utiliser ou non. Néanmoins, ce serait passer à côté de la puissance de Jelix.

Le cache

Au coeur de Jelix, il existe différents types de fichiers : XML, ini ou même des templates. Sans système de cache, à chaque requête utilisateur le framework serait obligé de lire les fichiers de configuration, de générer les templates, etc…
Fort heureusement, Jelix intègre un mécanisme de cache intelligent. Ainsi, les fichiers XML, ini, templates et autres sont traduits en code PHP pour la plupart et ensuite mis en cache pour éviter le processus décrit précédemment.
Si vous modifier un de ces fichiers, son cache va être régénérer à la prochaine requête utilisateur.

Abstraction des chemins d’accès

Il est souvent assez pénible de spécifier qu’on veut accéder à tel classe situé dans deux dossiers supérieurs à la classe qu’on est train de créer. Sous Jelix, les chemins sont représentés de la manière suivante module~nomdelaressource.

Url Rewriting

Pas forcément simple de devoir réécrire toutes les urls de vos différents modules et actions à l’aide de mod_rewrite ! C’est pour cela que Jelix permet à l’aide d’un simple fichier XML de mapper des urls sur vos modules et vos actions et aussi de typer les paramètres.

jDAO

C’est sûrement l’une des API les plus intéressantes de Jelix. jDao permet de représenter via un fichier XML (rédiger manuellement ou générer automatiquement à partir de votre base de données) vos différentes tables. Chaque table est représenter par un fichier XML mais il est possible également de combiner plusieurs tables ayant des relations dans un même fichier.
Au coeur de ses fichiers, il est aisé de rajouter des méthodes soit à l’aide de la syntaxe XML soit à l’aide de PHP.
L’immense avantage de cette API est qu’il est profite du cache géré par Jelix. Le gain de productivité n’est donc pas mise à mal par une éventuelle perte de performances.
Cette article parle de jDao face à d’autres ORM comme Doctrine.

jForms

C’est la partie formulaire de Jelix. Qui n’as jamais pesté contre la réalisation d’un formulaire avec validation client et serveur ?
jForms répond à cette problématique de la façon la plus simple qui soit. On décrit notre formulaire à l’aide d’un fichier xml et c’est terminé (il est possible également de le générer à partir d’un fichier dao). On aura les différents validateurs (client et serveur) qui seront mise en place en quelques lignes de code.
La prochaine version de jForms proposera un composant WYSIWYG pour la saisie de texte avancé ainsi qu’un captcha automatisé. Dans un avenir proche, jForms permettra de générer à partir du même fichier XML différents types de formulaires (Ajax, XUL, XForms).

Générateur de CRUD

Quoi de plus rébarbatif que la réalisation d’une page d’administration ? Pourquoi ne pas bénéficier des autres API ? Grâce à la combinaison des jForms et des jDao, il est possible d’obtenir une page d’administration avec toutes les actions possible (Création, Lecture, Mise à jour et Suppression) en seulement quelques lignes de code.

Les test unitaires

Les tests unitaires sont de plus en plus usités et c’est à ce titre que SimpleTest a été intégré à Jelix. Chaque module se voit greffer un dossier tests dans lequel on écrit des classes spécifiques qui vont permettre de vérifier que nos différentes classes marchent correctement.
Il suffit ensuite de les lancer soit en ligne de commande soit via une interface web dédié à cette effet. Il est possible bien sûr de lancer les tests individuellement, par module ou tous les tests.

Internationalisation

Quoi de plus problématique que la gestion de plusieurs langues au sein d’un même site internet ? Il faut déjà détecter la langue de l’utilisateur, passer par plusieurs librairies, fournir un fichier de langues à un traducteur, le retranscrire en fichier adéquate (gettext ou autre), s’assurer que ça marche bien sur le serveur de production… C’est n’est pas la panacée.
Pour résoudre ces différents problématiques, Jelix utilise des simples fichiers textes de clé valeurs comme par exemple :

Il est aisé de fournir ce fichier à un traducteur sans avoir à ensuite le retranscrire en fichiers gettext ou autre. Enfin, la détection de la langue du visiteur qui permet de changer la langue dynamiquement en fonction des paramètres du navigateur du visiteur. Cela permet d’avoir dés son arrivé sur votre site, une page dans la langue du visiteur.
Pratique non ?

Template

Le moteur de template est assuré par jTpl qui existe en version stand-alone.
jTpl a une syntaxe très proche de celle utilisé par Smarty, ce qui peut être un inconvénient pour certains développeurs mais la syntaxe est vraiment proche de celle de PHP en plus légère et permet de ne pas surcharger ses templates d’instruction PHP par forcément utile.
Il existe aussi des zones qui sont des portions de template qu’on veut pouvoir inclure au besoin sur les pages de notre choix et gérer de manière autonome du reste d’un template principal.

Les templates (zones y compris) bénéficient également du système de cache de Jelix.

Abstraction de la base de données

jDb est une API qui repose sur PDO et sur les librairies natives d’accès aux différentes bases de données (MySQL par exemple). Son avantage est de rendre l’usage de ses différentes librairies transparentes et d’uniformiser leurs utilisations.
Quelque soit la librairie choisi, vous utiliserez les mêmes fonctions et obtiendrez les mêmes ResultSet.

Connexion et gestion des droits utilisateur

Jelix fournit une API pour l’authentification utilisateur qui s’appelle jAuth. Elle est assez simple à mettre en place et se présente sous la forme d’un plug-in qu’il suffit de configurer en quelques lignes. Cela permet d’avoir simplement une gestion des sessions utilisateurs assez poussés sans effort. Au niveau du contrôleur, une ligne suffit pour indiquer que l’accés à tel ou tel action (ou l’ensemble des actions) sont réservés aux utilisateurs connectés.
Pour ce qui est de la gestion des droits utilisateurs, une autre API jAcl permet de gérer les accès utilisateurs à vos différents modules et actions. Il est possible ainsi de définir des groupes d’utilisateurs et leurs droits associés.
Cette API est un peu plus compliqué à mettre en place mais va être bientôt remplacé par sa version 2 avec un script de migration si je me trompe pas.

En conclusion

Il n’est évidemment pas possible de passer en revue toutes les fonctionnalités de Jelix, j’ai présenté assez succinctement les parties les plus intéressantes de ce framework qui mérite d’être encore plus connu.
Je vous invite à l’utiliser et pourquoi pas à contribuer si vous vous senter l’âme d’un contributeur.
Si vous désirez en savoir plus, je vous invite à venir sur le site officiel, à parcourir les forums ou à participer sur le channel irc dédié à cette effet.