Le but de cette section est de présenter RBS Change au développeur au travers d'exemples de code. Nous vous invitons à prendre connaissance du lexique
Le CMS RBS Change est développé à l’aide d’un framework PHP 5 orienté objet qui permet entre autres :
- Une abstraction objet du SGBD-R
- Gestion du multilinguisme
- Gestion de cache HTML
- Gestion indexation / recherche
- Gestion d’événements
- Gestion des workflows
- Gestion des URL “propres”
- Gestion des droits
- Classes utilitaires
- Mécanismes d’extension du fonctionnel standard
- Modélisation Model View Controller
- Organisation des Javascripts du projet
- Simplification de la problématique d’adaptation du CSS au navigateur
La couverture fonctionnelle est large et permet au développeur de rapidement produire des sites mettant en œuvre des fonctionnalités standards ou dédiées, dans un environnement structuré et adapté à son métier.
Le module rassemble du code, et des ressources (définitions de documents, classes PHP, configuration, gabarits, medias, …) qui gravitent autour d’un fonctionnel donné. Exemple : le module « blog » ou le module « formulaires ».
La structure d’un module est prédéfinie. Celle-ci est automatiquement initialisée par des commandes dédiées (change.php add-module) et le développeur en découvre les parties au fil de ses besoins. Un développeur réalisant des développements relativement standards n’aura en réalité à connaitre qu’une très faible partie de ces éléments (4 à 5 éléments ou plus).
Le document est l’unité de base de stockage pour RBS Change. Collection de « propriétés » de types divers (chaîne de caractères, entiers, booléens, fragment d’XHTML…), il représente un objet du monde « réel » (actualité, blog, site web, page, media…) et est en général administré par l’utilisateur final au moyen de formulaires dédiés.
Le cycle de vie des documents est normé et passe par des états bien définis (brouillon, en validation, actif, publié, archivé…) qui permettent de facilement greffer des workflows de publication notamment.
Il est structuré par un fichier XML permettant de définir les schémas de base de données indépendamment du SGBD utilisé. Le développeur n’interroge ainsi pas la base de données directement mais utilise une API objet qui lui permet de créer, modifier, interroger et détruire des documents.
Tout comme des objets PHP, les documents peuvent hériter entre eux et le développeur peut ainsi factoriser du code.
Un module peut définir un ou plusieurs documents.
Les blocs sont des fragments de page assurant une certaine fonction : lister les actualités de la rubrique courante, afficher la fiche détail d’un document, afficher le résultat d’une recherche… et dont l’utilisateur dispose pour composer sa page depuis l’éditeur de contenu de page du module « Site et Pages » (Voir plus bas).
Côté code, le bloc est matérialisé par une classe PHP, un ou plusieurs gabarits et une déclaration dans un fichier de configuration.
Les modules fournissent en général un certain nombre de blocs pour permettre l’affichage des documents gérés en back-office sur les sites gérés.
Le module « Sites et Pages » est un module central dans RBS Change : il introduit notamment les notions de site, de rubrique, de menu, de page et de bloc de page.
Le document site permet de régler des propriétés générales comme l’URL et le nom du site.
En dessous du site sont définis des rubriques et des pages. Une page sera en particulier élue « page d’accueil du site » : lorsqu’on accédera à l’URL du site, c’est cette page qui sera utilisée pour générer la réponse.
La rubrique est un conteneur de pages. On peut assimiler la rubrique à un dossier d’un site statique. En dessous d’une rubrique sont définis des sous-rubriques (sans limitation de niveau d’imbrication des rubriques) et des pages. Pour chaque rubrique, on pourra élire une de ses pages « page d’index de la rubrique » : lorsque qu’on accédera à l’URL de la rubrique, c’est cette page qui sera utilisée pour générer la réponse.
La page est le contenu de base des sites : que l’on demande l’affichage d’un site ou d’une rubrique, c’est au final une page qui sera utilisée pour générer la réponse.
Le formulaire du document page permet entre autre de régler le nom, les métas (titre, description, mots clefs), le modèle de page utilisé (gabarit), la publication (date de début, de fin d’affichage sur le site) et la visibilité de la page dans les menus ou le plan du site.
Le contenu de la page lui-même est géré par « l’éditeur de contenu de page », qui permet à l’utilisateur une saisie WYSIWYG grâce à laquelle il fournit des textes et agence les blocs dans les zones prévues par le modèle utilisé.
Le module « Site et Pages » permet la gestion de documents menus, représentant les menus de navigation du site. Les menus sont de deux types :
Le modèle de page définit souvent des emplacements à partir desquels il demande le rendu de menus ayant une certaine étiquette (tag) : « menu d’entête », « menu pied de page », « menu principal », … En affectant telle ou telle étiquette à ces menus, l’utilisateur a donc les pleins pouvoirs sur les menus de son site.
Au quotidien, le développeur utilise la ligne de commande, au travers des scripts framework/bin/change.php :
Connecté via SSH à son serveur de développement, il utilise des commandes simples, pleinement documentées et « auto-complétées » telles que « change.php create-new-project », « change.php add-document » ou « change.php add-block ». Le développeur peut facilement enrichir la ligne de commande avec des commandes spécifiques qu’il crée dans ses modules.
L’administrateur système peut également être amené à interagir avec une instance Change en utilisant des commandes telles que « change.php disable-site » qui permet de placer une instance en mode maintenance, ou encore « change.php apply-patch » qui permet d’appliquer un patch pour correction ou évolution du code du projet.
Au-delà de la productivité que le développeur gagne rapidement, l’existence de ces commandes permet de facilement « scripter » des actions sur les instances Change.