La philosophie : séparer contenu et design
🎭 Chapitre 3 — La philosophie : séparer contenu et design
Si l'on devait résumer InfraSStudio en un seul principe, ce serait celui-ci :
« Le design appartient au développeur.
Le contenu appartient à l'éditeur.
Les deux ne se mélangent jamais. »
Tout le reste — l'architecture du module, les choix d'interface, la façon dont les slots fonctionnent, la philosophie des permissions — découle directement de cette séparation stricte.
🎯 Pourquoi cette séparation est cruciale
Dans la plupart des CMS du marché, les deux mondes finissent par se mélanger. Le rédacteur a accès au HTML, au CSS, à la mise en page. Et il casse occasionnellement le site. Pas par malveillance : par inadvertance, parce que les outils l'autorisent à toucher à ce qu'il ne devrait pas.
InfraSStudio prend le parti opposé : verrouiller la structure et n'exposer à l'éditeur que ce que le développeur a explicitement marqué comme éditable.
Les bénéfices concrets
✅ Un client ne peut pas casser la mise en page
Il ne peut modifier que les zones balisées comme slots. Les conteneurs, les classes CSS, l'ordre des sections lui sont totalement inaccessibles.
✅ Le développeur peut faire évoluer le design
Sans casser le contenu. S'il refait la page d'accueil, les slots conservent leurs valeurs — il les replace au bon endroit dans le nouveau HTML, et le contenu remplit instantanément la nouvelle mise en page.
✅ La maintenance vit longtemps
Six mois plus tard, un autre développeur reprend le projet : il lit le HTML, voit les slots, comprend immédiatement quelles zones sont éditables et lesquelles sont fixes.
🔧 Comment c'est implémenté
La séparation n'est pas une convention molle. Elle est inscrite dans le fonctionnement technique du module à plusieurs niveaux.
1️⃣ Le HTML est la propriété du développeur
Le HTML d'une page Dolibarr Website est stocké dans deux endroits synchronisés : la base de données et un fichier .tpl.php sur le disque. InfraSStudio ne propose jamais à l'éditeur de modifier ce HTML.
- ❌ Pas de bouton « Voir le code source ».
- ❌ Pas d'éditeur de texte brut.
- ❌ Pas d'option cachée.
L'éditeur n'a accès qu'aux zones qui portent un slot. Le HTML environnant — les balises de structure, les classes CSS, les attributs — reste exactement comme le développeur l'a écrit.
2️⃣ Les slots sont auto-découverts
Quand le développeur ajoute un nouveau slot dans un template, il n'a rien d'autre à faire. Il ne déclare pas le slot quelque part dans une configuration séparée. Il ne crée pas une entrée en base de données.
Le module dispose d'un scanner qui parcourt automatiquement les fichiers .tpl.php du site, détecte les tokens {{slot:...}}, les enregistre dans la table llx_infrasstudio_slot, et génère l'interface d'édition correspondante.
<!-- Le développeur ajoute cette ligne dans son tpl.php -->
<h2>{{slot:section_title|type=text|default=Nos services|label=Titre de section}}</h2>Au prochain rescan (manuel ou automatique), le slot section_title apparaît dans le panneau d'édition de la page concernée. Pas de configuration intermédiaire.
3️⃣ Le rendu est complètement transparent
Quand un visiteur consulte la page publique, le navigateur ne voit jamais un slot. Le module intercepte le rendu, remplace chaque token {{slot:...}} par sa valeur courante, et envoie au navigateur du HTML parfaitement classique.
Cette substitution se fait au moment du rendu, pas au moment de l'édition. Le fichier .tpl.php sur le disque conserve les tokens originaux. Cela signifie :
- Le développeur peut lire et modifier le tpl.php sans craindre que les modifications de l'éditeur l'aient pollué.
- Si la table
llx_infrasstudio_slotest purgée, le site ne casse pas : les slots affichent leur valeur par défaut. - La portabilité est totale : exporter le code d'un site, c'est exporter le HTML avec ses tokens. Le contenu suit séparément, dans la base.
4️⃣ Les permissions matérialisent la séparation
Le module définit sept permissions distinctes dans Dolibarr, qui permettent d'attribuer à chaque rôle exactement ce dont il a besoin :
Permission | À qui la donner |
|---|---|
| Tout utilisateur qui doit voir le menu Studio |
| Lecteur seul (ex. un commercial qui consulte les pages avant un rendez-vous) |
| Rédacteur — peut modifier les slots de texte |
| Traducteur — peut éditer les versions linguistiques |
| Gestionnaire de médias — peut uploader / remplacer des images |
| Publicateur — peut basculer une page brouillon vers publié |
| Administrateur du module — accès configuration, sites managés |
💡 Combinaisons typiques — Un rédacteur reçoit readContent + editContent. Un traducteur reçoit editTranslations. Le développeur de l'agence garde admin. Personne n'a accès à des choses dont il n'a pas besoin.
🚫 Ce que la philosophie interdit (volontairement)
Pour rester fidèle à ce principe, le module refuse d'implémenter certaines fonctionnalités, même quand des utilisateurs les demandent.
Pas de page builder visuel
Vous ne pouvez pas glisser-déposer un bloc « titre » à côté d'un bloc « image ». La structure est figée par le développeur.
⚠️ Pourquoi ? — Les page builders visuels finissent toujours par produire des pages laides ou cassées dès qu'un utilisateur non formé s'en empare. La structure figée garantit la cohérence visuelle dans la durée.
Pas d'édition HTML « avancée »
Même un éditeur expérimenté n'a pas de mode « afficher le HTML brut ». Les slots de type richtext proposent un éditeur WYSIWYG (gras, italique, listes, liens, titres h2/h3) mais pas de bouton « source ».
⚠️ Pourquoi ? — L'édition de HTML brut est la première porte d'entrée des erreurs. Si une mise en forme spécifique est nécessaire, elle appartient au CSS (donc au développeur), pas au contenu.
Pas de « gestion de menus » côté utilisateur
⚠️ Pourquoi ? — La navigation est un élément de design, pas de contenu. Y toucher devrait être un acte délibéré, pas un effet de bord d'un clic mal placé.
Pas de logique métier côté slot
Les slots ne portent aucune logique conditionnelle. Vous ne pouvez pas dire « affiche ce texte uniquement si l'utilisateur est connecté ». Les slots sont purement des conteneurs de contenu.
⚠️ Pourquoi ? — La logique appartient au PHP (donc au développeur). Mélanger logique et contenu est la recette des CMS qu'on ne peut plus maintenir trois ans plus tard.
🏠 Une analogie : l'architecte et l'occupant
Pensez à un appartement qu'un architecte a conçu :
Rôle | Sa responsabilité |
|---|---|
📐 L'architecte | Dessine les murs, les ouvertures, les volumes, les prises électriques. Il pense au flux de circulation, aux proportions, à la lumière. Une fois le chantier livré, son travail est fait. |
🛋️ L'occupant | Choisit la peinture, le mobilier, les rideaux, les tableaux. Il vit dedans, change de canapé tous les cinq ans, repeint la chambre quand il a envie. |
InfraSStudio applique ce même découpage à votre site web. Le développeur est l'architecte : il livre des volumes définis. Le rédacteur est l'occupant : il vit dedans et l'arrange à sa façon, dans le respect des volumes existants.
Ni l'un ni l'autre ne marche sur les pieds de l'autre. Et cette discipline est la condition pour que le site reste vivant longtemps.