Blocs
Les blocs sont des éléments narratifs qui s’ajoutent à un objet pour le raconter : sur une page ou une actualité dans un site Web, sur une formation (dans un site d’école) sur une école (dans un site d’université) sur une personne (dans un site).
Les blocs répondent à des besoins plus ou moins sophistiqués, allant d’une image (avec son crédit, son texte alternatif et son alt) à un organigramme faisant référence à des personnes.
Nous utilisons des blocs notamment pour minimiser l’utilisation des éditeurs wysiwyg, qui génèrent du code problématique (HTML non valide). De plus, ce fonctionnement permet de gérer finement les enjeux d’accessibilité, et les comportements spécifiques (ex: actualités).
Pour faire fonctionner les blocs, il faut :
- un éditeur
- un modèle qui liste les dépendances
- un export statique
- une prévisualisation (mobile, offcanvas)
- une gestion des traductions
1. Editeur
Les éditeurs sont codés en Vue (parce qu’Angularjs est mort), et doivent permettre une variété d’entrées :
- chaîne de caractère (input text)
- texte long (textarea)
- texte rich (summernote, simple [b, i, ul, ol, a])
- sélecteur natif HTML
- sélecteur custom (liste de layouts)
- nombre
- case à cocher
- upload de fichiers
- éditeur d’objets composites (ex: images dans une galerie)
2. Modèle
Le modèle permet de :
- enregistrer les données json dans la base
- sanitizer
- encapsuler les logiques métiers (ex: les partenaires libres vs organisations, les articles non publiés…)
- lister les dépendances
3. Export
Les blocs doivent être exportables en Frontmatter pour Hugo.
4. Prévisualisation
Une prévisualisation est souhaitable, si possible :
- en temps réel (pas de temps de compilation)
- desktop et mobile
- avec les bons styles
Le précompilé ne permet pas simplement ces 3 souhaits, l’arbitrage actuel est mobile, sans style.
5. Traductions
Quelle logique ?
- Master + trads, avec le master qui reste en contrôle (logique “empilée”)
- versions autonomes, avec le “master” qui initialise la version, puis chacun vit sa vie (logique “séparée”)
Dev
Architecture
Le système est développé en 3 parties :
- blocks
- templates
- components
Le block est enregistré en base de donnée, et contient des données json. Il fait le lien avec l’objet auquel il est ajouté, et il définit son template. C’est un objet neutre, tout le spécifique métier est défini dans le template.
Le template répond à un besoin métier (un chapitre, un CTA, une galerie d’images, un organigramme…). Il définit un ensemble de components, qui vont permettre de générer les vues d’édition, de preview, d’export statique et de traduction.
Le component est un objet de bas niveau, comme un champ de texte ou une valeur booléenne. Il correspond à une propriété typée, et propose un éditeur standardisé (comme simple_form), une prévisualisation et un export statique.
Model
Tous les blocs possèdent un titre, un data en JSONB et une position.
Les attributs dans le JSONB côté Osuny peuvent avoir un type parmi :
string
: Champ texte classiquetext
: Champ textarearichtext (<config>)
: Richtext Summernote avec une configuration définie (mini
,mini-list
oudefault
)- exemple :
richtext (mini-list)
- exemple :
integer
: Champ de nombre entierfloat
: Champ de nombre décimalboolean
: Case à cocher (vrai/faux)enum (<value1>, <value2>[, ...])
: Enumération de valeurs possiblesreferences (<model>)
: UUID faisant référence à un objet avec le modèle associé- exemple :
references (Communication::Website::Page)
- exemple :
blob
: Champ d’upload de fichier (pour les images notamment), représenté par un objet ayant des attributsid
,filename
etsigned_id
array
: Pour un tableau d’élémentshash
: Pour un objet avec des paires clé-valeur
communication/Block
- university:references
- about:references (polymorphic)
- template:integer (enum)
- position:integer
- data:jsonb
Pour commencer, les valeurs de l’enum seront :
- 100, organization_chart
- 200, partners
Partial about
Un partial que l’on peut ajouter à un show d’objet, avec :
- la liste des blocs utilisés (avec boutons show et edit)
- la possibilité de les ordonner (position)
- un bouton pour ajouter un bloc
views/admin/communication/blocks/_list.html.erb
Show
Le show du bloc utilise le partial de son template
views/admin/communication/blocks/templates/partners/_show.html.erb
Edit
L’edit du bloc utilise le partial de son template
views/admin/communication/blocks/templates/partners/_edit.html.erb
Concern
Tous les objets ayant des blocs utilisent le concern WithBlocks
, qui ajoute la méthode blocks
(la liste des blocs, dans l’ordre).
Export statique
Les blocs sont exportés dans le frontmatter grâce au partial
views/admin/communication/blocks/_static.html.erb
qui donne ce type de résultat
blocks:
- template: partners
data:
- name: Partner 1
url: https://partner1.com
logo: "e09f3794-44e5-4b51-be02-0e384616e791"
Les générateurs de chaque type suivent l’organisation :
views/admin/communication/blocks/templates/partners/_static.html.erb
Attention, il faut 6 espaces pour respecter l’indentation du front-matter :
- name: Partner 1
url: https://partner1.com
logo: "e09f3794-44e5-4b51-be02-0e384616e791"
Dépendances
Il faut créer une classe pour chaque template, avec le nom au singulier (partners devient partner.rb, et la class Partner) :
models/communication/block/partner.rb
avec une structure de type :
class Communication::Block::Partner < Communication::Block::Template
def git_dependencies
...
end
end
Blocs dans l’extranet
En construction
Les blocs sont utilisés dans 4 contextes :
- Site Web en prod
- Extranet en prod
- Preview admin dans un contexte Site Web
- Preview admin dans un contexte Extranet
Dans les previews dans les sites, on utilise le style du site en allant les récupérer via l’URL du website.
Dans les previews dans les extranets, il faut utiliser le style de l’extranet.
Actuellement :
- Les extranets et les blocs de preview sont intégrés avec Bootstrap. Or, dans le thème, les blocs sont intégrés sans Bootstrap.
- Les DOMs des blocs sont à maintenir dans la partie back Osuny et dans la partie thème Osuny (et ça ne bouge pas).
2 solutions basées sur un site CDN Osuny qui expose un ficher de style spécial pour les blocs pour l’importer dans les extranets
- Solution Fast (avec Bootstrap)
- Le fichier de style gère également du style Bootstrap présent dans les extranets
- Solution Furious (sans Bootstrap)
- Remanier le front des extranets pour sortir la partie Bootstrap
- Ainsi, le fichier de style n’aura pas besoin de gérer du style spécifique Bootstrap
Pour créer un bloc
- Déclarer le template dans l’enum du modèle block
- Créer l’edit, le show et le static dans la vue du template
- Créer la classe du template pour gérer les dépendances
- Créer la vignette dans les images
- Ecrire les locales fr et en