Utiliser des gabarits

Posted 11 janvier 2011

Êtes-vous familiarisé avec l’utilisation de gabarit (ndt : on utilise aussi l’anglicisme Template) ? Connaissez-vous ce que c’est précisément ? Quel est son rôle ? Pourquoi est-il bénéfique d’en utiliser ?

En tant que web designer, je pense qu’il est tout de même intéressant de connaître ce qu’est exactement un gabarit, à quoi il sert et ce qu’il peut nous apporter de bien. Au jour d’aujourd’hui, j’avais une idée générale de ce qu’était un gabarit mais j’ai décidé de pousser mon savoir plus loin car je sais qu’il peut m’être d’une grande aide dans mon travail de tous les jours.

Lorsque vous travaillez dans une grosse structure qui traite énormément de sites, de pages, de création similaire etc. Il est précieux d’un point de vue général d’utiliser ce système qui offre un gain de temps incomparable lorsqu’il est bien pensé et bien utilisé.

Etude de cas

Voyons voir ce que l’on peut trouver sur la toile…

Premièrement le gabarit est également un template (terme anglais). Il a pour but la présentation des données, c’est un patron de mise en page ou l’on place images et textes. On parle aussi de « patron » comme en couture ou parfois de « grille ».

Dans la presse, un gabarit est conçu d’abord pour donner une forme cohérente à un journal. On définit un ou plusieurs gabarits qui seront utilisés dans une publication puis réutilisés durant différents numéros. Il a pour but de rendre claire la lecture et plus facile la conception. Les contenus, qu’il ‘agisse d’images (logos, illustrations) ou de textes (titres, légendes, colonnes de textes, etc.) seront placés à des endroits précis.

Par extension, en informatique, un template est un moyen de séparer le fond (le contenu informationnel) de la forme (la manière dont il est présenté).

Très utilisé dans la conception de sites webs, un template agit comme un modèle (une structure) dans lequel seuls certains éléments sont modifiables (le contenu et le style). Cela facilite la conception et la mise à jour des sites, aussi bien sur le contenu que sur la présentation.

* changer la charte graphique du site revient à changer le template et cela met à jour toutes les pages du site ;
* ajouter une page ne consiste plus qu’à en écrire le contenu

De plus en plus, la présentation d’une page Web est reléguée vers les feuilles de style (CSS : Cascading Style Sheets ou feuilles de style en cascade) externes à la page. Les templates ne sont donc plus seulement censés permettre une séparation entre la structure et la présentation mais aussi une séparation entre le code HTML ou XHTML et le code PHP (ou autre langage de développement côté serveur). On obtient ainsi une structure de site possédant d’un côté les traitements de données (calculs, connexion à des bases de données, sécurité) et de l’autre le « langage » de restitution des données produites. Cette séparation facilite le travail en équipe et les mises à jour soit du côté du code PHP soit du côté du code HTML puisque chacune des deux parties peut être modifiée sans affecter l’autre.

Les templates, utilisés conjointement à des feuilles de style efficaces, permettent de gérer la publication d’informations sur plusieurs supports différents.

Sur le système Django on nous dit :

Au chapitre précédent, vous avez peut être remarqué la façon particulière dont nous retournions le texte de nos vues d’exemple. À savoir que le HTML était codé « en dur », directement dans notre code Python.

Ce procédé engendre plusieurs problèmes :

Tout changement dans le graphisme de la page implique une modification du code Python. L’apparence d’un site a tendance à changer plus fréquemment que le code Python sous-jacent, il serait donc plus pratique de pouvoir changer l’apparence sans avoir à modifier le code Python.

Écrire du code Python et faire du design HTML sont deux disciplines différentes, et la plupart des environnements de développement professionnels séparent ces responsabilités entre des personnes différentes (voir même des départements différents). Les graphistes et les codeurs HTML/CSS ne doivent pas avoir à éditer du code Python pour faire le travail ; ils doivent avoir affaire au HTML.

De la même façon, il est plus efficace que les programmeurs puissent travailler sur le code Python pendant que les graphistes travaillent sur les gabarits, plutôt qu’une personne attende de l’autre qu’elle termine l’édition d’un seul fichier qui contient à la fois du Python et du HTML.

Pour toutes ces raisons, il est plus propre et plus maintenable de séparer le design des pages du code Python lui même. Nous pouvons faire cela avec le système de gabarit de Django, dont nous parlons tout au long de ce chapitre.

Sur dosimple on nous dit :

Les modèles HTML (Template)

L’HTML est un langage de structuration de l’information et non un langage de programmation comme le PHP. L’idée des modèles HTML (Template, Gabarits, Canevas) est de séparer ces deux parties afin de bénéficier de tout les avantages d’un découplage fort. Le but de cet article est d’illustrer comment fonctionne un système de Gabarit simple.

Il existe maintenant une nouvelle classe plus puissante.

Quand les utiliser ?

Alors que les feuilles de styles (CSS) permettent de séparer la structure du document et la présentation de ce même document. Les canevas permettent de séparer clairement la logique de programmation de la structure HTML.

Les canevas HTML servent à éviter le mélange sauvage de code HTML et de code applicatif. L’utilisation appropriée des gabarits dans votre application garanti un découplage total entre HTML et le langage de programmation.

Avantages

Cette façon de procéder permet d’acheminer son application vers le modèle de type « Modèle, Vue, Contrôle ». Il convient particulierement bien aux applications Web car la couche de présentation (Vue) se fait dans un langage différent de celui dévoué à la programmation (Contrôle et Modèle).

Robustesse

La modification de la présentation ne touche pas l’application, et inversement. Comme on peut se concentrer sur une plus petite partie du problème, on évite des erreurs.

Flexibilité

Le graphiste et le programmeur peuvent travailler ensemble sur l’application de manière non concurrente.

Clareté & réutilisabilité

La séparation fonctionnelle des langages facilite les modifications ultérieurs.