Les principaux atouts d'XCMS sont la dissociation de la forme, du fond et du format. Ainsi, à partir du même fichier (xcms.php), on peut obtenir un fichier de n'importe quel format. Actuellement, les formats supportés sont : HTML, XHTML, RSS, Atom, XUL et XCMSML. Cependant, un nombre illimité de formats différents peuvent être ajoutés selon les besoins.
Cet avantage est dû au fait que nous utilisons un système de templates comme il en existe beaucoup. Cependant, celui d'XCMS est volontairement très basique. En effet, alors que de nombreux systèmes de templates proposent une syntaxe propre permettant d'appliquer des conditions au contenu affiché et de faire appel à des variables etc... nous avons fait le choix de n'implémenter qu'un nombre limité de fonctionnalités.
Ceci pour trois raisons majeures :
Les templates sont des fichiers texte d'extension .tpl que vous trouverez dans les répertoires module/(nom_du_module)/(format). Le répertoire le plus utilisé étant module/system/html car il contient tous les templates de base, à commencer par index.tpl.
En effet, index.tpl est le fichier de template principal, celui à partir duquel le document final est créé. Pour illustrer nos propos, nous allons utiliser le fichier index.tpl du site d'Elitwork.
En visionnant ce fichier, vous remarquerez la présence en pagaille de plusieurs caractères tels que les @, #, % et les accolades ouverte et fermées. Ce sont les codes utilisés pour les cinq types d'actions possibles dans les templates d'XCMS :
Les templates XCMS permettent d'inclure d'autres fichiers de templates au sein d'un template. Ces inclusions sont délimitées comme suit :
#(code_inclusion)#
Par exemple, si nous reprenons le fichier index.tpl nous pouvons noter plusieurs inclusions :
Le chemin vers ces fichiers n'est pas spécifié dans les templates car il peut être modifié dynamiquement (comme pour le contenu), mais surtout, l'inclusion peut ne pas se faire si il n'y a rien à afficher (pas d'erreur, pas d'information, pas de sous-menu...).
La seule chose à retenir côté PHP c'est que l'inclusion est liée à la valeur $currentRequest->data['site_(code_inclusion)'] qui contient le chemin vers le template à inclure ou false (cas de non inclusion).
Il arrive que l'on veuille qu'une partie du document s'affiche de manière conditionnelle. Cela se fait grâce à la syntaxe suivante :
%(code_condition)%
Voici le contenu que je veux afficher de manière conditionnelle.
%/(code_condition)%
(code_condition) correspond en PHP à la variable $currentRequest->data['(code_condition)']; qui si elle retourne true ou tout autre contenu équivalent (texte, entier différent de zéro) affiche le contenu entre ses marqueurs.
Dans le document index.tpl, on peut, par exemple, noter que %document_configuration.adstyl% affiche, ou non, la feuille de style spécifique à la page en cours selon son existence.
La seule variante de ces conditions est la négation, qui s'utlise comme suit grâce au point d'exclamation :%!(code_condition)%
Voici le contenu que je veux afficher de manière conditionnelle.
%/!(code_condition)%
Il s'agit de remplacer un chaîne de la forme suivante {(code)} par la valeur dans PHP de la variable $currentRequest->data['(code)']. Par exemple, dans notre template, {document_title} contient le titre du document courant.
Vous avez peut-être remarqué que certaines conditions et impressions simples contiennent un point. Il s'agit d'une notation pour dire que la variable PHP visée se trouve dans un tableau. Par exemple, {document_configuration.adstyl} correspond en fait à la variable $currentRequest->data['document_configuration']['adstyl'].
Parfois, on souhaite afficher une liste d'items en boucle. C'est le rôle des arrobas. Pour afficher une boucle :
@(code_boucle)@
Une variable @(code_boucle).(variable)@ à afficher en boucle.
@/(code_boucle)@
Cela correspond au tableau $data['(code_boucle)'] et aux variables qu'il contient comme $currentRequest->data['(code_boucle)'][0]['(variable)'].
Dans notre document de référence, on ne trouve pas de boucle, voici donc le contenu du fichier module/system/html/error.tpl :
<!-- ERROR : Begin //-->
<dl id="error">
<dt><strong>{l_error_title}</strong></dt>
@site_errors@<dd>@site_errors.code@ : @site_errors.message@</dd>%visitor_isdevelopper%<dd>Debug : @site_errors.debugmessage@</dd>%/visitor_isdevelopper%@/site_errors@
</dl>
<!-- ERROR : End //-->
On peut remarquer que le message de déboguage n'est affiché que pour l'administrateur du site grâce à la variable $currentRequest->data['visitor_isdevelopper'].
Il est possible de créer une condition, à l'intérieur d'une boucle, sur une variable de cette même boucle. La notation dans ce cas est : %@(code_boucle).(variable)%(contenu de la condition)%\@(code_boucle).(variable)%.
Plus que plusieurs boucles imbriquées, l'impression arborescente est une boucle qui permet d'afficher du contenu arborescent sans connaître, à l'avance, le nombre de niveaux d'arborescence. Un peu comme pour le plan de notre site.
Pour ce faire, il suffit, à l'intérieur d'une boucle, d'utiliser cette syntaxe : @@(code_boucle).(variable)@@
Ce code insèrera le contenu de la boucle $currentRequest->data['(code_boucle)']['(variable)'] à l'endroit indiqué.
Pour information, voici le contenu de la boucle arborescente utilisée pour le plan de notre site :
<dl id="tree">
@tree@
<dt>
<a href="@tree.href@.html" title="@tree.shortdesc@">@tree.shorttitle@</a> :
@tree.title@
</dt>
<dd>@tree.description@</dd>
%@tree.child%
<dd><dl>
@@tree.child@@
</dl></dd>
%/@tree.child%
@/tree@
</dl>
Le système de template d'XCMS est simple afin que tous puissent le comprendre et le modifier. De plus, cela permet aux intégrateurs XHTML occasionnels de ne pas perdre de temps avec une courbe d'apprentissage trop longue, qu'ils soient référenceurs, designers ou programmeurs. Et puis, XCMS ne devient pas, du même coup, une usine à gaz complétement inexploitable, cela existait déjà avant... :-p