En tant que développeur Web, le premier système de templating auquel j’ai été confronté fût Smarty, au début des années 2000. Sans vouloir intégrer systématiquement Smarty à mes projets, son usage m’a familiarisé avec ses philosophies inhérentes et l’expérience m’aura inculqué un idéal de développement tendant vers le modèle MVC.
À mon avis, le problème avec Smarty est qu’il vient encombrer la pureté du HTML, du PHP et du CSS et s’ajoutant comme une dépendance supplémentaire au bon fonctionnement du site. Via plusieurs itérations de CMS maison, j’en suis venu à développer des techniques qui me permettaient d’émuler l’idéal de Smarty, à ma manière. Je ne m’en rendais pas compte à ce moment, mais ce qui avait été échangé contre une dépendance à Smarty était une dépendance aux divers noyaux des CMS que j’avais développés.
L’avantage était très mince et le produit final répondait plus spécifiquement à mes besoins qu’autre chose. Pire encore, l’introduction de nouveaux membres à ces projets requérait du temps supplémentaire afin que ceux-ci se familiarisent avec un système inconnu. Le problème restait le même, mais à défaut d’avoir trouvé une solution, j’avais au moins mis en lumière la nature du problème : Les systèmes de templatings sont encombrants et peu élégants parce qu’ils ne font pas partie même de la spécification du produit final; à savoir ici : le HTML.
À ce jour, les moteurs de templating pour le Web sont légion. Plusieurs se ressemblent, mais entre les différentes expertises, les développeurs n’ont pas réellement d’autres choix que de connaître les concepts, de maîtriser quelques systèmes de templating, mais de toujours demeurer dans l’éventualité très certaine de devoir un jour faire face à un système inconnu. Les développeurs Web sont habitués à ce genre d’adaptation, mais le temps et les énergies devraient êtres consacrées à autre chose que des apprentissages éphémères.
Tel que précédemment discuté, HTML5 fût une petite révolution qui est toujours en train prendre sa place. Parmi ses spécifications figure la balise <template>; un élément qui commence tout juste à être pleinement supporté et qui permet d’enfin libérer la notion de templating de moteurs encombrants.
La balise template remplit un besoin similaire aux moteurs de templatings existants, sans pleinement réaliser les fonctionnalités de ses prédécesseurs. Une plus grande liberté et une plus grande responsabilité est mise sur les épaules des développeurs. Ce qui est entendu par ceci, c’est que la balise <template> n’offre rien au niveau du data binding. Donc, pas de placeholders, pas de repeaters et pas d’énoncés conditionnels. Tout ces éléments logiques sont laissés à la charge du programmeur.
La logique derrière l’élément <template> est que son contenu est envoyé au navigateur sans être interprété, sans que son contenu soit chargé et sans que son code soit exécuté. Le code est simplement présent dans le document html, prêt à être utilisé au besoin. Au moment opportun, l’élément peut être invoqué/copié/manipulé via Javascript. Ceci est particulièrement utile lorsque le site Web ou l’application va chercher les données à afficher via Ajax.
Voyez l’exemple ci-dessous :
<template id="header_template">
<style>
#header_content{
width: 100%;
text-align: center;
}
</style>
<div id="header_content">
<h1>Bienvenue chez Wenovio</h1>
<img src="https://www.wenovio.com/wp-content/uploads/2016/11/logo-wenovio-1.png">
</div>
</template>
Nous avons créer un élément template qui contient des balises de style ainsi qu’un peu de contenu. Au sein d’un page HTML, ce code sera ignoré à l’affichage, mais sera accessible pour manipulation(via Javascript) une fois la page chargée. Voici un exemple de code Javascript qui, une fois exécuté, instancie le contenu de la balise template dans le body de notre page:
<script>
var template = document.querySelector('#header_template');
var clone = document.importNode(template.content, true);
var host = document.querySelector('body');
host.appendChild(clone);
</script>
Pour votre commodité, vous pouvez télécharger ce code sous forme d’exemple.
Ceci est un exemple très simple, mais si vous comprenez bien comment l’élément <template> fonctionne, il est aisé de voir comment vous pouvez développer davantage et intégrer ses fonctionnalités à vos projets, plateformes existantes.
Tel que mentionné, cette méthode ne remplace pas à 100% les moteurs de templating traditionnels, mais elle offre un excellent compromis qui ne vient pas alourdir l’application. On se retrouve aussi par défaut sans data binding, mais un programmeur un peu expérimenté pourrait aisément intégrer ces fonctionnalités avec une solution existante, des solutions plus largement supportées(Polymer ou x-tags) ou une solution personnalisée.
À l’instant, la balise <template> est supportée par beaucoup de navigateurs, mais pas tous. C’est donc une chose à prendre en compte lors de l’élaboration de vos solutions Web.
Au besoin, si vous devez détecter si un navigateur supporte la balise <template>, vous pouvez utiliser le code Javascript suivant et l’adapter selon vos besoins.
function template_able() {
return 'content' in document.createElement('template');
}
if (template_able()) {
alert("La balise template est supportée");
} else {
alert("La balise template n’est supportée");
}
Restez à l’affût des articles publiés sur le blogue de Wenovio; Un article plus élaboré concernant l’usage de l’élément <template> est à venir!
Exemple de code pour soumettre un formulaire avec CakePHP en utilisant Ajax et avoir un retour des erreurs de validation.
Nous discuterons spécifiquement de SQLite, ses particularités, ses avantages et quelques cas dans lesquels sont usage est pertinent ou souhaitable.
La refonte est une étape nécessaire dans la vie de votre site Web pour que celui-ci continue à servir vos objectifs de développement.
Avoir un site e-commerce est similaire à avoir une succursale ouverte 24/7 qui fait l’acquisition de clients pendant que vous dormez!