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

• Toute donnée (page, actualité, …) est “document”, décrit en XML : Change gère la création du schéma SQL
• API simplifiée d’interrogation objet des documents de la base de données : les requêtes complexes sur les arbres, les jointures, … , c'est RBS Change qui s'en charge !
• Héritage entre documents : tout comme les objets PHP, les documents supportent l'héritage ⇒ factorisation du code, maintenabilité accrue, …
• Gestion des versions de documents : historisation des différentes versions, détection des collisions entre rédacteurs, … Change s'en charge
• Cycle de vie normé des documents : de “brouillon” à “archivé” en passant par “publié” ou “En cours de validation” (workflow), le cycle de vie est clair, les transitions automatiques et paramétrables
• Organisation en structures arborescentes : gérer des arbres de documents, c'est simple et efficace !
• Gestion d’étiquettes (tags) : le rédacteur marque d'une étiquette un document, vous le retrouvez plus tard par code
• Importations XML : peuplez facilement votre base de données à l'aide de flux XML paramétrables
• Cache d’instances de documents : au niveau de la requête PHP et entre les requêtes, Change met en oeuvre des stratégies qui permettent d'encaisser de fortes charges

- Gestion du multilinguisme

• Internationalisation des messages utilisateur : faites simplement des interfaces multilingues
• Traduction de documents : déclarez vos documents traductibles et laissez Change faire le reste

- Gestion de cache HTML

• Description de dépendances
• Invalidation lorsque nécessaire

- Gestion indexation / recherche

• Quasi déclarative : gérer l'indexation des documents, c'est aussi simple que de concaténer de simples chaînes de caractères
• API objet de communication avec Apache SolR : LE moteur de recherche Open Source basé sur le célèbre Lucene.

- Gestion d’événements

• De nombreux événements autour du cycle de vie notamment
• Tout composant peut enregistrer des listeners pour se greffer sur les événements
• Tout composant peut définir et lancer ses propres événements

- Gestion des workflows

• Moteur de workflow complet
• Déclaration du XML
• Workflow de publication intégré au système
• Définition possible depuis MS Visio

- Gestion des URL “propres”

• Tout type document peut avoir son schéma de réécriture d’URL
• Définition des schémas de réécriture au format XML surchargeable
• Gestion des règles de ré-écriture au niveau du document
• Gestion des redirections

- Gestion des droits

• Modèle basé sur les rôles, attribué à des utilisateurs ou des groupes en des nœuds de l'arborescence du module
• Déclaratif, format XML, surchargeable.

- Classes utilitaires

• Réponse simple et normative aux problèmes courants du développeur
• Gestion des dates, mails, validation, tableaux, chaînes de caractères, XML, processus, graphiques, PDF, …

- Mécanismes d’extension du fonctionnel standard

• Surcharges de gabarits : tout gabarit est re-définissable
• Surcharges des messages utilisateurs internationalisés (“locale”) : embarqué dans le code projet ou depuis l'interface back-office, traduisez des éléments d'interface dans la langue de votre choix
• Surcharges des droits : tous les rôles des modules standards sont intégralement re-définissables
• Surcharges des documents par des sous-documents (“injection”) : tous les documents standards peuvent être remplacés par vos documents, en respectant les règles d'héritage Objet pour des adaptations pérennes, résistantes aux mises à jour de code
• Événements : votre code spécifique s'exécute en des points de rendez-vous prédéfinis
• Aspect Oriented Programming : greffez votre code sur celui des autres, proprement … ;)

- Modélisation Model View Controller

• Un modèle éprouvé et puissant
• Chaque couche a son rôle bien défini : gagnez en maintenabilité

- Organisation des Javascripts du projet

• Gestion des dépendances : n'incluez que ce dont vous avez explicitement besoin dans vos pages et évitez les doublons

- 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 :

• Automatique : les rubriques ou pages sœurs de la position actuelle du visiteur dans la structure du site sont listées, dans l’ordre définit par l’arbre du site. N.B. : on parle aussi de menu « contextuel ».
• Manuel : l’utilisateur final sélectionne des rubriques ou de pages, dans l’ordre de son choix.

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.