[FLUID]ifions nos intégrations TYPO3

Comme déjà évoqué dans les précédents articles sur le sujet, TYPO3 utilise maintenant le moteur de template FLUID.

L’avantage du système est qu’il est possible de l’utiliser dans l’ensemble des étapes de la mise en place d’un site, comme par exemple le développement d’extension (voir article sur le développement) ou l’ajout de fonctionnalité à une extension existante (voir article sur l’extension), mais aussi dans la phase d’intégration du site.

Les concepts et les avantages restent les mêmes quelque soit l’utilisation de FLUID, comme par exemple le fait de pouvoir utiliser des viewhelpers mis à disposition par d’autres extensions, ou mettre en place simplement des conditions au niveau de l’affichage.

A) Présentation de l’intégration dans TYPO3

L’intégration est une phase importante dans la mise en ligne d’un site. Elle consiste à transformer une maquette HTML statique en une vraie page web dynamique qui autorise la saisie et la modification des contenus.

Le principe de base est que TYPO3 va chercher à afficher un objet de type PAGE. Cet objet est lui même composé de plusieurs sous objet qui seront calculés puis l’ensemble de ces objets sera envoyé à l’internaute pour l’affichage de la page.

Les sous objets peuvent être :

un objet typoscript générique (de type TEXT, CONTENT, IMAGE, etc..)
un objet TEMPLATE
un objet FLUIDTEMPLATE

Comme on vient de le présenter il est possible de créer sa page intégralement sans utiliser de template HTML, en n’utilisant que des objets typoscript génériques… mais c’est vraiment pas top comme solution car :

le graphiste peut avoir à faire des retouches sur la maquette, et au moment du découpage HTML de cette maquette il faut retourner dans le code typoscript qui peut être compliqué
la moindre petite correction ne peut être faite que par un admin (accès enregistrement typoscript), ou par quelqu’un qui aurait accès aux fichiers typoscript externalisés
la page peut être composé de dizaines voir de centaines d’objets, et modifier quelque chose là dedans serait clairement une perte de temps importante.

Il est donc impératif de passer par un objet se basant sur un template HTML.

B) Différents objets de template

Il y a donc deux objets basés sur un template HTML

TEMPLATE
FLUIDTEMPLATE

Le premier est utilisé pratiquement depuis le début de TYPO3 (objet déjà présent dans la version 3.7.0) et encore très utilisé actuellement.

Le second a été ajouté avec la version 4.5 LTS

Nous allons comparer ces 2 objets en réalisation une (toute) petite intégration d’un template (vraiment) simple.

Le but sera de mettre en place, via les 2 techniques, les éléments suivants :

le titre de la page
un menu de navigation
une zone de contenu

Le template HTML est simple, voici le code :

 <html>
   <head>
     <title>Template démo</title>
   </head>
   <body>
     <div class="titre">Titre de la page</div>
     <div class="menu">Menu de navigation</div>
     <div class="contenu"><p>Zone de <i>contenu</i></p></div>
   </body>
 </html>

Et oui…on avait dit simple 🙂

Pour précision, on ne détaillera pas ici la construction des éléments « titre », « menu » et « contenu » car ce n’est pas le but de cette présentation.

Pour avoir un coté fonctionnel on simulera ces objets.

 lib.titre=TEXT
 lib.titre.value= Titre de la page
 lib.menu=TEXT
 lib.menu.value= Menu de navigation
 lib.contenu=TEXT
 lib.contenu.value= <p>Zone de <i>contenu</i></p>

C) Intégration via l’objet TEMPLATE (à l’ancienne)

Le fonctionnement du TEMPLATE se base sur l’utilisation de subparts et de marqueurs, comme on a pu le voir dans l’article sur le templating dans les développements.

Le template HTML doit donc être adapté pour intégrer ces marqueurs et subparts:

 <html>
   <head>
     <title>Template démo</title>
     <link href="style.css" rel="stylesheet"/>
   </head>
   <body>
     <!-- ###DOCUMENT_BODY### debut-->
     <h1 class="titre">###MARQUEUR-TITRE###</h1>
     <div class="menu">###MARQUEUR-MENU###</div>
     <div class="contenu"><!-- ###SUBPART-CONTENU### debut --><p>Zone de <i>contenu</i></p><!-- ###SUBPART-CONTENU### fin --></div>
     <!-- ###DOCUMENT_BODY### fin-->
   </body>
 </html>

On a donc :

une subpart délimitant la zone à prendre en compte (DOCUMENT_BODY)
un marqueur pour le titre (MARQUEUR-TITRE)
un marqueur pour le menu (MARQUEUR-MENU)
une subpart pour la zone de contenu (SUBPART-CONTENU, on aurait pu utiliser un marqueur mais on n’aurait donc pas parlé des subparts)

Le fichier HTML peut être consulté dans un navigateur car il inclut tous les éléments nécessaires à son affichage (comme par exemple l’appel aux CSS).

Passons à l’intégration typoscript… On va donc déclarer un objet PAGE, dans lequel on va ajouter objet TEMPLATE qui va lister les marqueurs/subpart.

Voici le code typoscript pour la mise en place du template principal :

 page=PAGE
 page.10=TEMPLATE
 page.10{
   template = FILE
   template.file = fileadmin/template/maquette.html
   workOnSubpart = DOCUMENT_BODY
   marks{
     MARQUEUR-TITRE<lib.titre
     MARQUEUR-MENU<lib.menu
   }
   subparts{
     SUBPART-CONTENU<lib.contenu
   }
 }

Voici le résultat obtenu avec un peu de CSS :

Résultat de l’intégration par la méthode des marqueurs

D) Intégration via l’objet FLUIDTEMPLATE

En regardant les propriétés de l’objet FLUIDTEMPLATE, on peut remarquer plusieurs différences :

l’écriture des « marks » change légèrement,
il n’y a plus de support des « subparts »,
il n’y a plus de propriété « workOnSubpart ».

Ce dernier point pourrait être particulièrement pénible pour les graphistes/intégrateurs qui doivent modifier une maquette HTML car le résultat attendu ne peut pas être testé (il n’y a pas le partie « HEAD » qui permet d’inclure les CSS).

Les modifications signalées impliquent donc des changements dans le template HTML :

on doit réécrire légèrement les markers actuels (appelés « variable »)
on doit supprimer les subparts et les remplacer par des « variables »
on doit supprimer le code non nécessaire (qui était précédemment à l’extérieur du marqueur « workOnSubpart »)

Le template HTML devient:

 <h1 class="titre">{MARQUEUR-TITRE}</h1>
 <div class="menu">{MARQUEUR-MENU}</div>
 <div class="contenu">{SUBPART-CONTENU}</div>

On constate que ce fichier template ne plus être vérifié directement dans un navigateur car il manque beaucoup d’information d’affichage.

On notera que le nom des variables a été volontairement laissé à l’identique par rapport à l’écriture précédente.

Passons à l’intégration typoscript… On reprend l’exemple précédent que l’on adapte.

 page=PAGE
 page.10=FLUIDTEMPLATE
 page.10{
   file = fileadmin/template/maquetteFLUID.html
   variables {
     MARQUEUR-TITRE<lib.titre
     MARQUEUR-MENU<lib.menu
     SUBPART-CONTENU<lib.contenu
   }
 }

Voici le résultat obtenu avec un peu de CSS :

Résultat de l’intégration par la méthode FLUID

On remarque que le contenu a été traité pour éviter l’interprétation des balises HTML (sécurité), il faut donc indiquer au moteur de template de ne pas traiter le code HTML reçu.

Cela se fait via le viewhelper de formatage <f:format.html>

Le template HTML devient donc :

 <h1 class="titre">{MARQUEUR-TITRE}</h1>
 <div class="menu">{MARQUEUR-MENU}</div>
 <div class="contenu"><f:format.raw>{SUBPART-CONTENU}</f:format.raw></div>

Voici le résultat obtenu avec un peu de CSS :

Résultat final de l’intégration par la méthode FLUID

Le résultat obtenu est équivalent à la présentation précédente.

E) Comparaison des solutions

La solution « TEMPLATE » semble plus simple à gérer avec son template qui pouvait présenter l’intégralité du montage HTML d’une vraie page, et aussi par le support des « subparts » qui pouvait être intéressantes pour laisser en place des données de « simulation » dans le template HTML.

Cependant la solution « FLUIDTEMPLATE » présente l’ensemble des avantages issus de FLUID (comme cela a été vu dans les précédents articles).

Par exemple, il est possible de gérer simplement la bascule entre 1 et 2 colonnes de contenus, en intégrant une condition dans le template FLUID.

 <h1 class="titre">{MARQUEUR-TITRE}</h1>
 <div class="menu">{MARQUEUR-MENU}</div>
 <div class="contenu"><f:format.raw>{SUBPART-CONTENU}</f:format.raw></div>
 <f:if condition="{data.layout}==1">
   <f:then>
     <div class="contenu2">...contenu zone 2...</div>
   </f:then>
 </f:if>

La condition sur {data.layout} permet d’activer ou désactiver la colonne supplémentaire en fonction de la valeur « layout » pour la page actuelle.

Évidemment, il y a de nombreuses manières de gérer ce cas, et il est tout à faire possible de le faire avec la solution « TEMPLATE » mais cela aurait nécessité d’utiliser plusieurs templates HTML, ou du typoscript pas facile à maintenir avec l’intégration de balise HTML directement dans le typoscript via un wrap par exemple.

Mais si gérer une ou deux conditions est faisable via l’ancienne méthode, cela devient compliqué lorsqu’il faut en gérer de nombreuses. Le nombre de templates explose ou le typoscript devient assez vite très compliqué.

On peut aussi intégrer directement l’ensemble des viewhelpers disponibles et on pourrait même imaginer intégrer directement le viewhelper <evolutionfluid:contacter> créé dans l’article Fluidifions nos évolutions et cela sans aucun développement php, ni typoscript.

2 commentaires

MICHELET Clément dit :
1 avril 2015 à 13 h 28 min
L’article est plutôt simple et concis. Cependant, c’est fort dommage, on ne voit pas l’avantage ni une réel différence avec FLUID. La notion de Layout est abordée mais de manière trop succincte et strictement de la même manière qu’en TS. C’est fort dommage car c’est son point fort pour réellement « fluidifier » nos développements.
> l’écriture des « marks » change légèrement,
Non, ce sont toujours des marqueurs avec un caractère différent (mais pouvant être modifier en TS).
> il n’y a plus de support des « subparts »,
Non, on a toujours la notion de « subparts » mais plus complexe dans FLUID: condition, iteration, section, partial, etc.
On peut intégrer strictement de la même manière qu’à « l’ancienne » juste en modifiant nos appels pour le faire façon FLUID. Lors d’une mise à jour, on peut conserver la majorité des TS mis en place et faire appel à ces TS via un viewhelper.
La grosse différence étant la solution derrière : une syntaxe de configuration contre un moteur de template.
OlivierSC dit :
2 avril 2015 à 9 h 02 min
Merci pour cette réaction à chaud 🙂
Le but de cet article n’est pas de présenter l’ensemble des fonctionnalités techniques disponibles dans FLUID ou les liaisons avec le noyau TYPO3.
L’idée est de se mettre dans la tête de quelqu’un qui ne maitrise pas FLUID, qui utilise encore les anciennes méthodes et de voir comment il est possible de basculer simplement.
Toute la série d’article FLUID est sur ce principe « ancien VS nouveau ».
Concernant les remarques :
En effet, les LAYOUT sont une partie très intéressante dans FLUID, et mériterait même un article dédié (si le coeur t’en dit 😉 ) mais dans le cas d’une simple bascule depuis une ancienne intégration sans réinventer la roue, ils ne sont pas vitaux.
Concernant les « marks », il faut se replacer dans le contexte de l’article et comprendre « l’écriture typoscript pour déclarer un marqueur change légèrement » (« marks » devient « variables « , on ne peut pas faire plus léger comme changement 😉 ).
L’écriture change mais le concept reste le même et c’est clairement le but de l’article que de montrer qu’il est simple de basculer entre l’un et l’autre.
Concernant les subparts (et dans le seul cadre de l’intégration générale), pour moi leur seul intérêt était de pouvoir simuler du contenu pour rendre la maquette HTML plus réaliste (I love lorem).
En dehors de ce seul avantage, ils étaient totalement en doublon avec les « marks » et c’est, à mon avis, pour cela que le principe n’a pas été conservé dans FLUID.
A côté de ça, en jouant sur les mots et le la technique, on peut arriver à un comportement équivalent, mais cela n’a pas vraiment d’intérêt vu que de toute façon l’ensemble de la maquette ne peut plus être consultable (donc inutile de simuler du contenu), et que pour le mettre en oeuvre, il faut savoir ce qu’on fait ce qui n’est pas forcément le cas d’un débutant.
Pour le débutant, un subpart n’est pas « simplement » remplaçable par « condition, iteration, section, partial, etc. », donc autant faire oublier tout de suite la notion de subpart telle qu’elle existait avant 😉
Enfin : « On peut intégrer strictement de la même manière qu’à « l’ancienne » juste en modifiant nos appels pour le faire façon FLUID »
C’est EXACTEMENT le but de cet article 🙂
Il s’agit de montrer qu’en changeant un tout petit peu ses habitudes mais sans non plus devoir repartir de zéro, il est possible de basculer sur une intégration FLUID.
L’avantage final était d’être 100% sur FLUID pour avoir le temps (et le courage) d’approfondir ses connaissances et de jouer avec les viewhelpers, les conditions, layout, partial, la gestion des traductions et des liens, etc…

Laisser une réponse

Cliquez ici pour annuler la réponse.