Omacronides 4.0 : FlatCMS

FlatCMS : gestionnaire de contenu

Le framework de publication de contenu obéit à une architecture classique modèle-vue-contrôleur, où l'on sépare ce qui est de l'ordre de la requête (contrôleur), de la gestion (modèle) et de l'affichage (vue) des données. Une répartition du travail qui peut se comparer (partiellement) à celle qui existe dans un document web où l'on distingue la structure (HTML), la présentation (CSS) et le comportement (javascript).

La philosophie de l'outil reste la même : il s'agit toujours d'une collection de scripts PHP qui vont chercher les données dans des fichiers plats, sans autres fioritures. La gestion MVC est fortement inspirée par celle de CodeIgniter.

Le travail de FlatCMS s'articule ensuite avec celui des autres modules décrits brièvement ci-dessous tout en conservant certaines exigences du précédent cahier des charges, comme la possibilité de publier les contenus à la volée sans rien faire d'autre que de placer un fichier dans un dossier.

FlatDB : gestion de la base de données

La gestion du contenu en lui-même n'a que très peu évolué, si ce n'est là aussi dans la formalisation des procédures sous forme de module indépendant. Le module permet d'analyser des données stockées dans des fichiers xml ou des fichiers texte à syntaxe définie, ainsi que de récupérer les fichiers dans une structure hiérarchisée de dossiers.

La principale évolution fournit la possibilité de déclarer des « services » pour chaque document, ce qui permet d'associer du code CSS ou javascript spécifiquement à certaines pages web.

Enfin, un objet parallèle à la base de données permet de manipuler un fichier xml obéissant à une DTD simple afin de gérer une liste d'items. Il est utilisé sur le site pour stocker des liens pré-définis, les acronymes, les tags ou les catégories.

Template : système de mise en page

Le rendu des données sous forme de page HTML résulte de la même problématique qui a présidé à la création de FlatCMS - et à celle de ses incarnations antérieures : ne trouvant pas d'outils adaptés à mes besoins, soit parce que trop complexes, soit au contraire parce qu'ils manquaient cruellement de fonctionnalités, il m'a fallu en développer un moi-même.

Là encore, j'ai uniquement formalisé ce qui existait déjà dans la version 3 du site sous forme d'une classe Template. Elle fonctionne de la manière suivante :

• Un template général (page web) dans lequel est affiché la vue adéquate en fonction de la page demandée.
• Pas de langage de balise spécial pour allourdir l'interprétation du code ; PHP est déjà à l'origine un langage de template. Les données sont considérées comme des membres de l'instance de la classe, l'assignation des données et leur affichage étant assurés par une surcharge du getter et setter de membres.
• Quelques méthodes de test et une méthode de boucle pour parcourir un sous-ensemble de données.

EasyCache : système de mise en cache

J'ai utilisé pendant longtemps jpCache. Le projet semble avoir été abandonné et 2 forks ont vu le jour. Même s'il s'agissait d'une solution légère et assez simple à mettre en place, je souhaitais écrire quelque chose d'encore plus léger, qui tienne en une seule classe PHP. C'est chose faite. La classe possède des fonctionnalités de base :

• Activation / Désactivation
• Définition d'un temps de mise en cache

StxParser : parser de syntaxe wiki

Le convertisseur de syntaxe wiki a été elle entièrement réécrit. Je ne suis pas certains que les performances en soient améliorées, il faudra effectuer quelques tests pour cela, mais il s'agissait d'une évolution importante et indispensable pour rendre le système à la fois modulaire et extensible. Il est maintenant pleinement autonome, avec la possibilité pour l'utilisateur de personnaliser et d'étendre ses fonctionnalités en surchargeant les classes de rendu. Il devrait voir le jour sur le site en tant que projet à part entière.

Au niveau des évolutions, la syntaxe des tableaux s'est enrichi de la possibilité de séprarer les lignes de données par une ligne de pointillés afin de rendre le tout plus lisible.

Je rappelle que ce parser de syntaxe wiki a débuté il y a 2 ans comme une adaptation du wiki2xhtml d'Olivier Meunier.

Intégration de la librairie javascript rnb

Un dernier point technique a consisté à intégrer au site une librairie javascript que j'ai commencé a constituer dés mes premières expérimentations dans le domaine, début 2005. Pendant un an, les morceaux de code sont restés eparpillés de-ci, de-là, jusqu'à ce que je me décide à regrouper le tout dans un espace de nommage cohérent.

Cette intégration explique que de nombreux articles du site soient encore indisponibles. Il me faut trouver un moyen de présenter les scripts sans avoir à maintenir une foultitudes de copies. C'est d'ailleurs en grande partie pour cela qu'un nouveau type de document est apparu : les « projets ».

Apparition des projets

Le site ne gérait jusqu'à présent que 2 types de documents : des articles et des notes. Avec la structuration du code javascript en librairie autonome, il y avait besoin de séparer plus clairement ce qui relevait du rédactionnel des ressources qui présentaient du code et autres expérimentations. Donc de scinder en deux les antiques articles, avec l'apparition d'un nouveau type de document : les « projets ».

La gestion des archives

La plupart des modifications dans la gestion du site au cours de ses 4 années d'existence furent pour partie imputables à d'éternels tâtonnements dans la manière de classer / organiser les documents. Avec la nouvelle version, j'espère avoir trouvé un système de gestion satisfaisant.

Pendant longtemps (deux premières moutures du site), la classification par catégorie a pris le pas sur la classification par date, simplement parce qu'il s'agit de la manière dont je préfère effectuer mes recherches. Sont ensuite arrivés les tags (version 3), ce qui a un peu compliqué les choses. Et il y a pour finir les types de documents avec la dichotomie notes / articles, qui est devenu une « trichotomie » (sic !) avec la mise en place des projets.

Le but du jeu a donc été :

• De regrouper tous ces modes de classification (catégorie, date, tag, type) au sein d'une même interface d'utilisation.
• De pouvoir associer ces différentes classifications pour effectuer des recherches sur plusieurs critères, comme « rechercher tous les articles publiés en mars 2007 dans la catégorie web ».
• De permettre d'effectuer des requêtes où un champ peut avoir plusieurs valeurs, comme « rechercher les notes plubiées en 2008 ET 2007 ».

La nouvelle structure du module de gestion des archives n'en est encore qu'à ses balbutiements ; de nombreuses choses restent à améliorermais l'api ne devrait plus changer. Comment cela se traduit-il au niveau des urls ?

• L'adresse de la page d'archive se construit à partir du nom des 4 « champs » de classification : date, cat, tag et type.
• L'assignation d'une valeur à un champ se fait par le signe « = ».
• La déclaration de plusieurs valeurs pour un champ se fait en les séparant par une virgule « , ».
• L'association de différents champs se fait par le signe « & ».

Si l'on reprend les deux exemples de requêtes ci dessus, cela nous donne :

• « tous les articles publiés en mars 2007 dans la catégorie web » : /archives/date=200703&cat=web&type=articles/
• « les notes plubiées en 2008 ET 2007 » : /archives/date=2008,2007&type=notes/.

Caractéristiques :

• Si aucun type n'est spécifié, les trois types de documents seront recherchés.
• On ne peut pas associer plus de 5 valeurs aux champs multiples (date, cat et tag).