Ma vision concernant l’intégration de contenus et de pages avec TYPO3

Temps de lecture estimé: 15Min

Suite à mon article sur « ma vision pour Fluid, J’aimerai décrire une autre vision liée à ce sujet. Alors que ce premier article est principalement à propos de ce que l’on peut faire avec le moteur de templating Fluid en dehors de TYPO3, cet article parle plutôt de ce que l’on peut faire avec Fluid au sein de TYPO3. Nous partons du principe que la vision du premier article est réalisée.

La projection peut être résumée comme suit:

Nous devrions pouvoir, en glisser/déposer, remplacer et/ou ajouter des templates de contenus, au lieu de devoir utiliser une grosse quantité de paramétrages et de configuration. Nous devrions avoir une méthode native dans le core pour gérer les contenus imbriqués.

C’est en fait plus simple qu’il n’y parait. Nous avons déjà tous les principes qui nous permettent de le faire – la seule chose qu’il reste à faire c’est de décider comment combiner ces principes pour donner le meilleur résultat aussi bien pour les utilisateurs que les développeurs.

Voici les quelques changements simples mais vitaux que j’imagine pour TYPO3.

Types de contenus et templating

Je propose l’approche suivante en ce qui concerne le templating des éléments de contenus dans TYPO3, en instituant les principes suivants:

1. Chaque contenu est associé à un template Fluid
2. Le template associé est nommé comme un CType et formaté par exemple comme ceci: Text.html, Media.html etc.
3. Le contenu est rendu par un ContentController
   1. Celà peut être fait avec un controler par CType ou,
   2. Cela peut être fait par un controler mutualisé et une action par CType
   3. La classe du controler peut être surchargée partiellement, en utilisant des metadata, de la configuration, convention+detection etc.
4. Les templates par défaut sont fournis dans EXT:frontend/Resources/Private/Templates/Content/
5. Les CType‘s disponibles sont detectés en scannant les templateRootPathsconfigurées pour plugin.tx_frontend.view
6. Une procédure de recouvrement est utilisée, si certains CType ont plus d’un template, le premier detecté est utilisé.
7. Le TCA du sys_template possède un champ select renderMode=checkboxes préremplis avec la liste des CTypes detectés pour activer ou desactiver des « content types ».

En implémentant cette approche nous allons être en mesure d’ajouter des nouveaux types de contenus tout simplement en faisant un cliquer / déposer d’un template Fluid dans n’importe quel des chemins qui ont été configurés pour contenir des templates. Nous ne detectons plus quels types de contenus on peut utiliser en analysant la configuration ajoutée manuellement. (cependant par soucis de compatibilité il faut continuer à supporter cette méthode !) – à la place, nous detectons quels templates peuvent être rendus et on les proposes comme types quand l’éditeur crée un nouveau contenu. On autorise le remplacement des rendus actuels simplement en déposant un template nommé comme un core type – et notre template est utilisé à la place. Si nous avions besoin d’un process plus personnalisé, nous pourrions créer une classe controler qui prendrait en charge l’initialisation de la vue, entre autre.

Ce n’est pas tout, nous pouvons aussi créer des templates séparés, pour différents formats. Par exemple inclure des rendus XML ou plaintext des contenus natifs, via templates Fluid, le choix du template à utiliser est géré par le choix du format.

L’apparence des champs utilisés par les éditeurs lorsqu’ils configurent un élément de contenu (les colonnes TCA) peut aussi être configuré ici – cependant nous aurions besoin de pouvoir prendre en compte un changement de schéma ou d’utiliser un stockage relationnel qui ne requiers pas de changement de schéma. Quoi qu’il en soit, ce sont des détails techniques qui ne doivent pas affecter la vision dans son ensemble.
Petit détail: Flux utilise déjà du TS qui qui peut définir les metadatas pour les templates, permettant à l’integrateur de surcharger ce qu’il veut sans modifier les fichiers de templates de contenus.

Ce dont nous avons besoin pour une telle solution est déjà présent. La compatibilité avec les méthodes de configuration existante est possible ( en gardant la configuration historique en tant qu’alternativ). Ce que nous devons faire est une manière de définir des métadata dans les fichiers de templates – si vous arrivions à finaliser la fonctionnalité « déposer et remplacer » avec un seul fichier. Flux est capable de faire celà en incluant autant de métadonnées dans le template que nécessaire.

En fournissant le selecteur mentionné ci dessus pour l’enregistrement sys_template, nous donnons à l’administrateur du site une option parfaite pour blacklister ou whitelister certains types de contenus n’importe ou dans l’arborescence, et le tout via une interface visuelle au lieu de le faire en TSconfig par exemple)

Et, bien sûr, nous rendons possible de complètement remplacer chaque aspect de la manière dont notre contenu est rendu n’importe ou dans le site, en configurant simplement un chemin additionnel de template qui contient des surcharges. Et comme le TS est hérité sur les pages filles, nous pouvons répéter ceci autant que nous le souhaitons pour surcharger les types de contenus au fur et à mesure que nous nous enfonçons dans l’arborescence.

Note à propos des plugins, qui ne sont pas des Ctypes

Dans TYPO3 nous avons le contenu « plugin », qui partage la valeur CType avec les autres plugins et qui utilisent un champ list_type comme second paramètre pour indiquer quel plugin rendre. Il est possible d’arriver à traiter un imbriquement encore plus profond, ex: EXT:myext/Resources/Private/Templates/Content/ListType/SpecialPlugin.html (c’est un sous package) mais ceci n’est pas ideal. Ce que je propose à la place est de (discrètement) commencer à s’éloigner de cette façon de créer les « plugins », pour plutôt se rapprocher d’une solution qui propose des méthodes basées sur des conventions qui autorisent les éléments de contenus à être crées de manière à appeler le controller du package

Tout ceci est lié à une autre vision que j’ai: Permettre à TYPO3 de detecter et automatiquement intégrer certaines fonctionnalités en observant juste un nom de classe, un fichier de template etc..

Templating de page

En prenant la même méthode que ci-dessus et en l’appliquant aux templates de page, nous pouvons mettre en place la convention ci-dessous:

1. Chaque « type d’affichage » de page est associé à un template Fluid
2. Le template associé peut être nommé librement et utilise Default.html par default
3. Le template de page est rendu par un PageController (même logique que le ContentController)
4. Les templates par défaut sont fourni dans EXT:frontend/Resources/Private/Templates/Page/
5. Les « types d’affichages » disponibles sont detectés en scannant les templateRootPaths pour des plugin.tx_frontend.view
6. Comme pour les contenus, une procédure de surcharge est utilisée
7. Le TCA du sys_template se voit ajouter un champ similaire à celui du contenu, avec la possibilité de white-black lister.

Pour faire simple, nous appliquons la même convention que pour la détection des types de contenus et l’utilisons pour les types d’affichage des pages.
Le type d’affichage des pages est l’équivalent d’un CType pour les pages. Le terme « type d’affichage » est utilisé ici mais ce n’est pas forcément le nom définitif – il faut cependant faire attention aux conflits, sachant qu’il existe déjà un champ « Layout » qui pourrait être facilement confondu avec le Fluid Layout.

De la même façon que pour l’intégration de contenu, la plupart des besoins techniques existent déjà – et sont même plus simples à gérer en terme de compatibilité et de rétro-compatibilité que les types de contenus.

La combinaison des suggestions ci-dessus sont, pour faire simple, les fonctionnalités clés des extensions fluidpages, fluidcontent et fluidcontent_core.

Les contenus imbriqués (colonage par exemple)

Nous avons besoin d’une gestion des contenus imbriqués dans le CORE. On doit absolument en avoir – Je suis complètement d’accord!
Les pré requis pour une telle intégration sont aussi simples à lister qu’ils sont complexes à implémenter:

1. Nous avons besoin de quelque chose de compatible avec les backend_layout
2. De préférence quelque chose de compatible aussi avec le modèle des DataProvider
3. Quelque chose qui peut être utilisé par un utilisateur plutôt simplement (je veux dire avec une interface graphique)
4. Quelque chose qui puisse être implémenté à tous les niveaux: un type de contenu du CORE, un plugin, un contenu personnalisé, ou même un enregistrement (exemple concret: la fonctionnalité de l’ EXT:News qui est capable de faire un lien à un tt_contentpourrait être remplacée par une grid)

Nous stockons actuellement ceci dans un format proche du TS dans un champ de la DB. Cette méthode est ok pour le moment.

Ce que je propose est que créer un nouveau type de champ dans le TCA, qui appliquerait automatiquement un « wizzard TCA » pour définir une interface graphique qui serait éditée visuellement et qui stoquerait la définition du contenu imbriqué. Nous avons déjà un wizzard en popup qui pourrait faire l’affaire – il doit juste être intégré pour être vraiment utile. Il suffit d’intégrer ce wizzard dans n’importe quel contenu, incluant les pages, tt_content, be_layout et les autres, pour pouvoir éditer leur apparence dans le backend.

Ensuite, quand le module page detecte qu’un enregistrement ( dans ce cas un tt_content) possède une grille associée, un sous-rendu est réalisé qui utilise un marker de colonnes secondaire pour indiquer:
1. Le contenu parent
2. Le colonage grille

L’objectif principal techniquement est de pouvoir réutiliser le rendu de la grille du module page dans un sous-contenu.

Conclusion

Les visions décrites ci-dessus rendraient très simple la gestion du templating dans TYPO3 – Vous auriez un moteur de template extrêmement puissant et son intégration serait automatisée.
Un autre bénéfice inattendu de tout cela et que nous nous débarrasserions de ce message « page type is not defined! » par défaut quand l’utilisateur n’a pas chargé de distribution – à la place, il verrait un beau template par défaut (qui pourrait même lui afficher un tutorial).

L’expérience utilisateur serait améliorée en frontend, et en backend, en lui proposant un joli selecteur qui permet de changer le template de page – ce qu’il est probablement habitué à avoir dans les extensions.
Nous intégrons tout ce là avec sys_template pour une améliorer aussi l’expérience de l’administrateur.

Côté développeur, c’est bien évidemment beaucoup beaucoup mieux que. En fonction du niveau d’automatisation ( par exemple nous pourrions même essayer de detecter les templates de Content et Page dans toutes les extensions installées et utiliser leur ordre de chargement comme ordre de surcharge, supprimant ainsi le besoin d’ajouter des chemins en Typoscript) nous pourrions encore améliorer l’expérience du développeur.

Enfin, en choisissant Flux comme moteur de metadata pour les templates, nous bénéficierions d’une vraie fonctionnalité de surcharge par dépos d’un fichier. Les développeurs ou intégrateurs n’aurraient qu’a créer un nouveau fichier de template et l’éditer au besoin, puis de l’uploader, et TYPO3 comme par magie créerait toutes la configuration que vous avez à faire aujourd’hui.

Sur du très long terme, celà permettrait aussi de déprécier beaucoup du code de rendu des contenus dans le core, pour le remplacer par des méthodes spécifiques au sein de packages TYPO3.

J’allais oublier…

Il n’y a rien qui nous empêche aujourd’hui de livrer ce genre de package de templates pour les contenus et les pages comme dépendances « composer », sans aucune metadata spécifique TYPO3 autour.
Si je reviens sur ma vision à propos de l’intégration de Fluid avec d’autres frameworks, qui peut dire qui ne serait pas non plus possible de créer des adaptateurs pour ces frameworks, qui permettraient aussi d’utiliser les principes évoqués dans l’article. Ex: Un driver page/contenu TYPO3 pour Flow ou autre.

Merci d’avoir pris le temps de lire mes pensées !

Claus

Article traduit de l’original: https://gist.github.com/NamelessCoder/1d189c200e07619f9bce#file-content-page-vision-md
Suivez Claus Due sur Twitter : https://twitter.com/namelesscoder
Retrouvez son projet sur https://fluidtypo3.org