Pluf et Jelix
The 2007-11-12 at 20:26 by Loïc d'Anterroches filed under News.
Un lecteur m’a posé la question de savoir que choisir entre Jelix et Pluf. Je n’ai pas de réponse toute faite, car le choix d’un framework est une question de goût. Voici par contre mon avis. Il est bien entendu biaisé puisque je suis le créateur de Pluf. Voici donc une présentation de Pluf et quelques points très limités de Jelix. Je ne connais que peu Jelix.
L’histoire de Pluf est étroitement liée avec mon utilisation du framework Django écrit en Python. En effet, j’ai eu besoin de développer une application complexe avec la contrainte de devoirs utiliser PHP. Je ne pouvais pas utiliser un autre langage. J’ai alors décidé de réimplémenter les éléments que j’appréciais (et apprécie toujours) de Django en PHP.
Avec Pluf vous avez un ORM qui permet de facilement faire des choses genre :
$auteur = new Auteur(); $auteur->nom = 'Loïc'; $auteur->create(); $article = new MonArticle(); $article->titre = 'Mon titre'; $article->contenu = 'Ici un long contenu...'; $article->auteur = $auteur; $article->create(); // Maintenant on recherche les articles écrits par // cet auteur. $articles = $auteur->get_monarticle_list(); assert($articles[0]->id == $article->id);
Les class Auteur et MonArticle doivent simplement étendre la
class de base Pluf_Model. Cela vous donne directement le stockage
possible dans une base de données SQLite, MySQL ou
PostgreSQL.
Après l’ORM, vous avez des vues pour afficher les données et un
controlleur pour faire la sélection de la vue en fonction de
l’URL. Par exemple, vous pouvez dire que l’URL /article/32/
correspond à la méthode afficherArticle de votre class
MesVues. Vous avez un contrôle complet des URL et de leur format
car vous les définissez avec une simple expression régulière. Voici un
extrait :
$ctl[] = array('regex' => '#^/article/(\d+)/$#',
'priority' => 4,
'model' => 'MesVues',
'method' => 'afficherArticle');
La priorité permet de mettre en avant les URL les plus utilisés pour éviter de passer à travers toutes les expressions régulières.
Maintenant pour afficher une page, on peut simplement mettre dans la méthode afficherArticle :
function afficherArticle($request, $match)
{
$article = new MonArticle($match[0]);
$ct = $article->title."\n\n".$article->contenu;
return new Pluf_HTTP_Response($ct, 'text/plain');
}
Voici une méthode très simple qui renvoie même pas de l’HTML, mais simplement le titre et le contenu de l’article. Il n’y a même pas de vérification si l’article demandé existe. Pour faire le contrôle on peut utiliser un raccourci.
function afficherArticle($request, $match)
{
Pluf::loadFunction('Pluf_Shortcuts_GetObjectOr404');
$article = Pluf_Shortcuts_GetObjectOr404('MonArticle', $match[0]);
$ct = $article->title."\n\n".$article->contenu;
return new Pluf_HTTP_Response($ct, 'text/plain');
}
Dans ce cas là, cela voudrait dire que si l’article n’existe pas dans la base de données, une exception de type 404 va être lancée et une erreur 404 sera affichée, sinon la page normale sera affichée.
Le fait d’avoir un objet $request et un objet Pluf_HTTP_Response permet d’avoir des méthodes pour modifier la requête avant la vue et modifier la réponse après la vue. Ce sont les middlewares, ils permettent de faire la gestion des sessions, la validation du code, afficher des informations de debuggage, etc.
Pluf est très léger et permet de facilement utiliser des librairies venant de PEAR.
Avec ceci, vous avez la base de Pluf. Pluf n’impose rien d’autre et en fait vous n’avez même pas besoin d’utiliser tous ces éléments, vous pouvez utiliser juste l’ORM ou juste le dispatcher. Pluf est très léger et généralement vous aurez un process d’environ 2 Mo pour une vue avec l’ORM, le dispatcher, etc.
Maintenant, ce que j’aime dans JELIX. En fait, 2 choses, le système de templates. Tellement sympa que je l’ai repris et étendu pour l’utiliser dans Pluf. L’autre, c’est le principe d’un objet réponse qui assure que la réponse sera toujours comme voulu soit de l’HTML, XML ou Jason.
Le problème que j’ai avec JELIX (note que j’utilise des composants développés par Laurent Jouanneau dont j’apprécie la qualité du code) c’est l’utilisation importante des fichier XML pour ensuite générer dynamiquement des fichiers PHP (alors que PHP 5 permet de faire cela proprement et facilement sans passer par XML) ainsi que l’utilisation importante de conventions qui je trouve "personellement" lourdes :
Par exemple pour supporter un site avec de multiples langues, on se retrouve dans le code avec :
ma_fonction ()
{
$chaine = jLocale::get("bar~foo.buttons.save");
}
là où avec Pluf on a simplement:
ma_fonction ()
{
$chaine = __('Sauvegarder');
}
Par ailleurs l’utilisation importante de ce concept de selecteurs rend le code pour moi difficile à lire et surtout cela devient difficile de faire cohabiter des modules venant de différents auteurs car il faut alors maintenir une configuration pour Jelix et une pour les autres modules qui utilisent normalement des chemins normaux vers les fichiers.
L’autre chose qui m’ennuie c’est le fait d’imposer une structure très particulière pour la position des fichiers .php sur le serveur comment gérer cela avec les modules venant d’autres frameworks ou de PEAR ? C’est possible mais cela ajoute de la complexité.
Dans le cas de Pluf. Une classe MonProject_MaClasse est simplement
dans le fichier MonProjet/MaClasse.php avec le répertoire MonProjet
dans un répertoire qui est dans le PATH de PHP. Mais on peut toujours
faire un "include_once ‘/mon/fichier/class.php’". C’est d’ailleurs la
convention retenue par PEAR pour la version 2 de PEAR.
Maintenant, l’important c’est d’essayer les deux en faisant une petite application. Cela permet de "sentir" si on aime ou pas. En effet, c’est souvent beaucoup une question de goût…
Sub Categories
Sites I like
Mon entreprise
Logiciel libre
Sur ce site
Comments from readers
Bastien Jaillot said:
Bonsoir,
Je suis un fervent utilisateur de Jelix mais seulement depuis peu. Avant de me mettre au PHP5 avec Jelix, j'utilisais CodeIgniter qui était en PHP4.
CodeIgniter, hormis sa limitation évidente d'être en PHP4 était à mon avis plus comparable de Pluf que de Jelix. Je l'adorais. Mais il me proposait surtout "une aide au développement", plus qu'un véritable framework.
Je n'ai pas encore beaucoup testé Pluf, mais en tout cas j'arrive à faire des choses extraordinairement puissantes avec mes daos et un controller dao perso.
Jform, les JResponses, les daos me sont maintenant vitaux.
Le framework souffre encore de jeunesse, du manque de contributeur. J'essaye de faire mon possible pour aider au développement, mais je ne me suis pas encore fait à tout.
Pluf m'a l'air sympa, mais je le considère désormais comme mon CodeIgniter, l'outil facilement dispo pour mes applis simples : pas besoin de sortir l'usine à gaz pour deux tables par exemple.
Bonne continuation sur Pluf, je l'ai mis en cron automatique pour la récupération des svns.
Et au passage, je suis abonné depuis longtemps à ton blog, et je n'avais jamais entendu parler de Pluf ou alors vraiment rapidement. C'est dommage.
loïc m. said:
Salut,
je pense que c'est une très bonne présentation de Pluf ;)
Peut-être devrai-tu faire un petit lien sur la liste de discussion vers ton article, pour avoir une présentation un poil plus détaillé de Pluf :)
Loïc said:
Bonjour Bastien,
Merci pour cette longue réponse. Pour ce qui est de la communication sur Pluf, c'est un peu normal qu'elle soit limitée, en effet je me concentrais sur son utilisation plus que sa publicité. J'essaye maintenant de réparer cette erreur.
J'apprécie particulièrement ta réponse car elle exprime bien pour moi la différence entre Jelix et Pluf. Mon but avec Pluf est de rester simple et efficace.
J'ai mis en place une application qui a supporté avec succès 500 utilisateurs simultannés pour la gestion d'une conférence scientifique, mais je peux faire un petit gestionnaire de formulaire avec insertion dans une base de données des résultats très facilement.
En fait, plus je code, plus je vois la beauté dans la simplicité. Pluf est vraiment une recherche de simplicité.
Je vais continuer de faire connaître pluf dans le futur et je te souhaite bien du plaisir avec Jelix, car c'est certain, c'est un bel outil.
Laurent said:
>c’est l’utilisation importante des fichier XML pour ensuite générer dynamiquement des fichiers PHP
C'est voulu : on a ainsi un aspect déclaratif plutôt que programmatif. Cela a à mon sens plusieurs avantages :
- c'est plus simple à lire
- c'est rend les choses plus simples à écrire (y a qu'à voir le code PHP généré correspondant...) Une seule balise peut parfois économiser de nombreuses lignes en PHP.
- c'est facilement manipulable par un outils tiers (ex un plugin pour eclipse qui permettrait d'éditer visuellement ces fichiers)
- Certains de ces fichiers peuvent être générés par de simple commande en ligne
> alors que PHP 5 permet de faire cela proprement et facilement sans passer par XML
Je ne comprend pas ce que tu veux dire...
>Par ailleurs l’utilisation importante de ce concept de selecteurs rend le code pour moi difficile à lire
Les sélecteurs rendent complètement abstrait les urls et les fichiers. Par exemple, pour indiquer une url vers une action, on utilise un sélecteur, et non pas l'url directement. Cela a trois gros avantages, surtout pour les projets conséquents :
1) on sait tout de suite à quoi ça correspond, et où aller voir dans le code ladite action, sans avoir à passer par le fichier de mapping url->action
2) si on change l'url dans le fichier de mapping, il n'y a rien à changer ailleurs dans le code.
3) lors de l'installation d'un module tiers : aucunement besoin de modifier lesdits modules pour les urls. Suffit juste de modifier le fichier de mapping de l'application
Autre exemple : les sélecteurs pour désigner un template, une classe métier d'un module etc.. Il arrive que l'on ait à bouger des modules d'un répertoire à un autre (pour mettre en commun des modules entre plusieurs applis par exemple). Cela reste complètement transparent vis à vis des autres modules. Aucune ligne de code à modifier.
>surtout cela devient difficile de faire cohabiter des modules venant de différents auteurs car il faut alors maintenir une configuration pour Jelix et une pour les autres modules qui utilisent normalement des chemins normaux vers les fichiers.
Ça c'est le problème avec de nombreux frameworks aussi. De toute façon, il faut faire attention à l'utilisation de classes externes. Pour certaines, cela peut faire doublon avec ce que propose le framework, et l'application devient alors un bloatware. Par exemple, il n'est pas très conseillé (même si c'est tout à fait possible) d'utiliser des classes PEAR avec Jelix, parce qu'avec PEAR, on va se retrouver avec plein de trucs en doubles (l'accés aux base de données par exemple, qu'il va falloir configurer deux fois).
> L’autre chose qui m’ennuie c’est le fait d’imposer une structure très particulière pour la position des fichiers .php sur le serveur
Il y a une structure particulière, mais c'est tout à fait normal. Dans un contexte professionnel, où on a 15 projets à maintenir, l'utilité d'avoir une structure permet de s'y retrouver beaucoup plus rapidement et donc de corriger ou faire évoluer rapidement une appli, en tout cas bien plus que si chaque appli a été fait en empilant des classes venant de toutes parts. D'ailleurs, c'est la définition même d'un framework : "cadre de travail". Un projet qui se dit framework sans imposer une structure, sans imposer un cadre de conception, n'est selon moi pas un framework, mais une bibliothèque. PEAR n'est pas un framework par exemple.
Enfin, rien n'interdit d'ajouter une classe externe à jelix : le répertoire lib est fait pour ça. Un include dans un contrôleur ou une classe métier, et ça fonctionne parfaitement. (jelix embarque nativement des libs externes...)
En ce qui concerne la localisation, on pourrait faire un alias __ vers jLocale::get. Par contre, utiliser les phrases pour les clés à la gettext n'est franchement pas maintenable. Si tu utilises par exemple le même terme un peu partout, et qu'un jour tu veuilles changer, il faut que t'aille modifier partout ce terme. Avec un système à clé comme jelix, tu as juste les fichiers de langues à changer. D'ailleurs jelix n'a rien inventé, c'est le même principe utilisé dans des gros projets comme mozilla, les applis java etc...
Loïc said:
Merci Laurent pour venir présenter ici les avantages de Jelix d'une bien meilleure manière que moi.
En fait, je suis complètement en accord avec toi sur le bloatware, mais en désaccord avec l'utilisation d'XML (je n'utilise pas d'IDE pour coder) et la localisation. Pour la localisation, je préfère l'approche "gettext" car cela permet de localiser facilement à posteriori. Pour le moment Pluf n'est pas localisé, tout est prêt, mais la localisation reste à faire. J'aurais utilisé un système de clefs comme Jelix/Java/Mozilla, j'aurais du faire un travail important pour définir ces clefs et les "remplir" avant même de pouvoir exécuter mon code.
Pour ce qui est des sélecteurs, c'est un concept effectivement très élégant. Mais si ce n'était que moi, je ne l'utiliserais que pour les URLs et pas plus. Avoir de la souplesse au niveau des URLs est nécessaire, par contre, je ne pense pas que cela soit foncièrement nécessaire pour les accès vers les fichiers.
leseb said:
Jelix 1.0 est disponible. Que des bonnes choses ;-)