CakePHP, c'est du gateau

200819/02

Le site change une nouvelle fois de peau motorisé par un framework PHP étonnant : CakePHP.

Les raisons du changement

Après 3 ans de bons et loyaux services qui ont vus ce site propulsé par une solution maison PHP / MySQL, le désire de changer de peau est apparu après avoir été totalement plagié graphiquement par un site Québécquois.

Si notre CMS propriétaire, élaboré depuis 2004, répondait parfaitement aux attentes de gestion de publication du site, disons qu'il était bien de pouvoir étendre le champ des compétences.

Aussi, il fallait pouvoir faire un choix sur un framework PHP performant, bien documenté, et présentant des garanties sérieuses sur ses couches applicatives. 

Les frameworks testés 

Les frameworks testés ont été les suivants :

• EZPublish
• Plone
• Joomla
• Wordpress
• Drupal
• CakePHP

Certains, comme Drupal ou Wordpress n'ont pas été retenus car déjà maîtrisés et en applcation sur certains sites.

Joomla, ex-mambo, possède des qualités certaines, notamment au niveau du back-office, mais de voir que des centaines (plus ?) de développeurs s'associent pour monter un projet Open Source (qui n'est pas récent puisqu'il y a eu Mambo auparavant), et ne font toujours pas l'effort minimum de se mettre aux standards du W3C, ça laisse sceptique sur les compétences générales.

Plone est un CMS saisissant de puissance, de rapidité, de simplicité. Il ne mettait qu'une seule contrainte : me mettre au langage Python.

EZPublish, une solution Norvégienne, est également parmi les meilleurs CMS Open Source du marché, qu'on compare (en mieux) à Typo 3. Mais il nécessite des ressources serveur très fortes. C'est un CMS pour des sites gros comptes.

Viennent ensuite trois concurrents laissés de côté : Symfony, Prado et Jelix. Je dois pas être assez "geek" pour utiliser des framework en ligne de commande, il y a quelque chose qui ne me séduit pas dans cette approche.

Puis est venu le moment de tester CakePHP. On trouve très peu de documentation, et donc d'avis du côté francophone, malgré ses 3 ans d'age. Par contre, la communauté anglophone est très bien organisée et  la documentation très complète.

Les tests furent réellement satisfaisant et le choix fut fait ! 

Pourquoi CakePHP ?

La question est normale. Au regard de ce que ce site propose, il est évident que des CMS comme Wordpress ou Dotclear auraient permis de monter un tel site bien plus rapidement.

L'idée générale reste un goût de la découverte de nouvelles solutions, de pouvoir étendre mes domaines de compétences, afin de pouvoir à l'avenir proposer des solutions plus rapidement montées et pérennes. 

CakePHP n'est pas un CMS mais un framework qui va servir à construire des applications.

Une architecture MVC 

L'architecture Modèle/Vue/Contrôleur (MVC) est une façon d'organiser une interface graphique d'un programme. Elle consiste à distinguer trois entités distinctes qui sont, le modèle, la vue et le contrôleur ayant chacun un rôle précis dans l'interface.

L'organisation globale d'une interface graphique est souvent délicate. Bien que la façon MVC d'organiser une interface ne soit pas la solution miracle, elle fournit souvent une première approche qui peut ensuite être adaptée. Elle offre aussi un cadre pour structurer une application.

Dans l'architecture MVC, les rôles des trois entités sont les suivants.

• modèle : données (accès et mise à jour)
• vue : interface utilisateur (entrées et sorties)
• contrôleur : gestion des événements et synchronisation

Rôle du modèle

Le modèle contient les données manipulées par le programme. Il assure la gestion de ces données et garantit leur intégrité. Dans le cas typique d'une base de données, c'est le modèle qui la contient.

Le modèle offre des méthodes pour mettre à jour ces données (insertion suppression, changement de valeur). Il offre aussi des méthodes pour récupérer ses données. Dans le cas de données importantes, le modèle peut autoriser plusieurs vues partielles des données. Si par exemple le programme manipule une base de données pour les emplois du temps, le modèle peut avoir des méthodes pour avoir, tous les cours d'une salle, tous les cours d'une personnes ou tous les cours d'une groupe de Td.

Rôle de la vue

La vue fait l'interface avec l'utilisateur. Sa première tâche est d'afficher les données qu'elle a récupérées auprès du modèle. Sa seconde tâche est de recevoir tous les actions de l'utilisateur (clic de souris, sélection d'une entrées, boutons, …). Ses différents événements sont envoyés au contrôleur.

La vue peut aussi donner plusieurs vues, partielles ou non, des mêmes données. Par exemple, l'application de conversion de bases a un entier comme unique donnée. Ce même entier est affiché de multiples façons (en texte dans différentes bases, bit par bit avec des boutons à cocher, avec des curseurs). La vue peut aussi offrir la possibilité à l'utilisateur de changer de vue.

Rôle du contrôleur

Le contrôleur est chargé de la synchronisation du modèle et de la vue. Il reçoit tous les événements de l'utilisateur et enclenche les actions à effectuer. Si une action nécessite un changement des données, le contrôleur demande la modification des données au modèle et ensuite avertit la vue que les données ont changé pour que celle-ci se mette à jour. Certains événements de l'utilisateur ne concerne pas les données mais la vue. Dans ce cas, le contrôleur demande à la vue de se modifier.

Dans le cas d'une base de données des emplois du temps. Une action de l'utilisateur peut être l'entrée (saisie) d'un nouveau cours. Le contrôleur ajoute ce cours au modèle et demande sa prise en compte par la vue. Une action de l'utilisateur peut aussi être de sélectionner une nouvelle personne pour visualiser tous ses cours. Ceci me modifie pas la base des cours mais nécessite simplement que la vue s'adapte et offre à l'utilisateur une vision des cours de cette personne.

Le contrôleur est souvent scindé en plusieurs parties dont chacune reçoit les événements d'une partie des composants. En effet si un même objet reçoit les événements de tous les composants, il lui faut déterminer quelle est l'origine de chaque événement. Ce tri des événements peut s'avérer fastidieuse et peut conduire à un code pas très élégant (un énorme switch). C'est pour éviter ce problème que le contrôleur est réparti en plusieurs objets.

Interactions

Les différentes interactions entre le modèle, la vue et le contrôleur sont résumées par le schéma de la figure suivante.

Sources : http://www.liafa.jussieu.fr/