7 Bonnes Raisons D'abandonner Templavoilà, [MàJ] : Dmitry Dulepov quitte l'équipe de TemplaVoila! Options

[duch]

On m'a souvent entendu dire que TemplaVoilà était une mauvaise extension, une usine à gaz et j'en passe, et en général quand je dis ça, je passe pour un allumé... (ce qui n'est pas complètement faux)

Voici donc, ci-dessous 7 preuves tangibles de ce que j'avance (comme ça vous verrez que j'ai encore quelques neurones intactes)
Bon en fait, si vous cherchez bien, il y en a 9, mais ça faisait moins sympa que 7 alors...


1. TemplaVoilà est une usine à gaz :

Vous êtes vous déjà amusé à mesurer le nombre de lignes de code que représente l'extension TemplaVoila? Non, alors voilà les chiffres (mesurés avec la version 1.4.1) :

Code

-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
PHP                             48           2984           6686          13808
XML                             23             36              0          10537
CSS                              2            167             19            828
Javascript                       2             16              4            108
SQL                              1             10              0             91
HTML                             2              0              0             37
-------------------------------------------------------------------------------
SUM:                            78           3213           6709          25409
-------------------------------------------------------------------------------

Oui, vous avez bien lu, plus de 25000 lignes de code, et pour faire quoi? un CMS complet? Non, un simple système de templating, ouah, ça c'est de l'efficacité, et ça laisse présager de la suite...

Il est d'ailleurs très amusant (voir hilarant) de constater que Dmitry Dulepov (le lead developper de TemplaVoilà) invoque la "Parabole des 2 programmeurs" dans son livre pour apprendre à programmer une extension


2. La structure de base de données de TemplaVoila est absolument inefficace :

Dans Typo3, les pages sont stockées dans la table "pages" et les contenus dans la page "tt_content", la liaison se faisant sur le champ pid (qui permet de savoir dans quelle page est stocké le contenu)
Lorsqu'on utilise le module "Pages" standard de Typo3, il est très simple de savoir dans quelle colonne se trouve un contenu, cela est indiqué dans le champ colPos.
Pour savoir si un contenu a été effacé, c'est simple également, il suffit de tester si le champ deleted de l'enregistrement est égal à 1.

Donc pour récupérer les contenus de la page 1, c'est assez simple (j'ignore certains champs techniques pour une meilleure compréhension) :
SELECT * FROM tt_content WHERE hidden=0 AND deleted=0 AND pid=1

Comment cela se passe maintenant avec TemplaVoilà?
Avec TemplaVoila, la position d'un contenu dans la page n'est pas portée par l'enregistrement du contenu lui même mais est stockée dans un champ de la table "pages" sous la forme d'un XML qui correspond à la Data Structure (DS) choisie pour la page (sur lequel il est donc impossible de faire la moindre requête).
De plus, quand vous supprimez un élément de contenu depuis l'interface de TemplaVoilà (et pas directement dans le formulaire d'édition de l'élément de contenu), l'élément n'est jamais marqué comme effacé dans la table tt_content, il est juste supprimé du XML stocké dans la table "pages" et apparait dans le back-office sous "Éléments non utilisés"

Donc concrètement, comment récupérer un élément de contenu d'une zone particulière? Et bien, cela se passe en 3 étapes :
- on récupère le contenu du XML dans la table pages
- on parse le XML afin de récupérer la liste des ids de contenu stockés dans la zone donnée
- on fait maintenant une requête similaire à la précédente sur la table tt_content en indiquant la liste des ids à récupérer

Efficace? Non, et encore vous n'avez rien vu


3. Il est impossible de faire une recherche dans la table tt_content avec TemplaVoilà :

Imaginez qu'un client vous demande de réaliser un petit module qui va recenser tous les éléments de contenu d'un type particulier utilisés sur le site (c'est du vécu).
Si vous utilisez le module pages standard de Typo3, c'est très simple et ça se passe en 2 étapes :
- on génère une liste d'id de pages afin de filtrer les contenus qui seraient stockés dans une page cachée ou effacée (on ne sait jamais)
- on fait cette simple requête SQL : SELECT * FROM tt_content WHERE CType='mon_type' AND hidden=0 AND deleted=0 AND pid IN('.$pid_list.')

Comment faire avec TemplaVoila?
Comme vu ci-dessus, un élément supprimé depuis l'interface de TemplaVoilà n'est pas marqué comme tel. Il est donc impossible de faire une simple requête pour récupérer tous les éléments de contenus visibles dans un site (ou même un page, une section, bref, nul part). Il va donc falloir mouiller la chemise (et affoler le CPU) :

Le cas simple, vous n'utilisez pas de FCE :
- on récupère la même liste que quand on utilise le mode "pages" comme vu ci-dessus
- on boucle sur chaque enregistrement (oups, ça se corse)
- pour chaque enregistrement, on récupère le pid le la page parent
- on récupére le XML stocké dans la page parent
- on parse chaque XML pour vérifier si le contenu est utilisé dans la page

Le cauchemard, vous utilisez des FCE :
je ne vais pas détailler la méthode mais sachez que si votre contenu est stocké dans un FCE, le FCE lui même n'est peut être pas utilisé dans la page, je vous laisse donc imaginer le nombre de boucles nécessaires pour vérifier ça...

NB : En théorie, on devrait pouvoir utiliser la table sys_refindex pour accélerer ces traitements, mais d'expérience, d'une part elle est rarement à jour, et de plus, je ne connais aucun programmeur qui sache vraiment l'utiliser.

Alors, TemplaVoilà, toujours aussi génial? oui? Bon ok, je continue


4. TemplaVoila rend la maintenance d'un site difficile

Bien conscient des problèmes évoqués ci-dessus, les développeurs de TemplaVoilà ont introduit un outil qui permet de nettoyer les éléments non utilisés.
Cet outil est lancé en ligne de commande via l'extension lowlevel :

php typo3/cli_dispatch.phpsh lowlevel_cleaner tx_templavoila_unusedce -s -r

Problème, la structure de la base est tellement alambiquée que lancer cet outil sur un site dont la volumétrie est importante est tout simplement impossible (c'est du vécu aussi), on a beau pousser le memory_limit et le set_time_limit à fond, et faire tous les réglages possibles et imaginables, le CPU s'emballe pendant de longues minutes et le script plante invariablement.

Enfin, peut-être n'ai je jamais eu de chance... Je continue?



5. TemplaVoila ne permet pas d'exploiter pleinement le Typoscript.

EDIT : Rakel a démontré avec un certain brio qu'il était possible de contourner le deuxième problème, donc le deuxième argument tombe et je le retire (même si honnêtement, je trouve la solution plus compliqué que la méthode classique, mais je m'incline).
Ne reste reste donc que le premier argument qui est toujours parfaitement valide sur le papier mais peut être contourné via l'utilisation d'une extension.

Il y a certaines fonctions Typoscript qui ne peuvent pas être utilisées conjointement avec TemplaVoilà, entres autres :

- La fonction "slide" :
Une fonction très pratique qui permet d'hériter des contenus de pages en pages. On peut par exemple poser un contenu sur la page d'accueil et en utilisant l'objet typoscript CONTENT conjointement avec la propriété slide=-1, il est hérité sur toutes les sous-pages (pratique pour un bandeau de pub par exemple).
Avec TemplaVoila, on est obligé d'utiliser une extension supplémentaire pour faire ça : kb_tv_contentslide

- Afficher un contenu de manière aléatoire :
Une astuce très pratique de l'objet CONTENT consiste à utiliser un orderBy = rand() afin de remonter un contenu au hasard (encore mon fameux bandeau de pub).
Problème, à ma connaissance, on ne peut pas utiliser l'objet CONTENT conjointement avec TemplaVoilà, on est obligé d'utiliser l'objet RECORDS, et cet objet ne permet pas de passer des paramètres spécifiques à la requête (logique puisqu'on lui passe directement un id d'enregistrement via la propriété current=1)

Et il y en a sans doute d'autres... Je continue ou vous avez déjà abandonné TemplaVoilà?


6. TemplaVoilà alourdit votre base de données :

Un petit test amusant à réaliser avec TemplaVoila :
- dupliquer la table "pages"
- supprimer les champs relatifs à TemplaVoilà sur la copie...

Tada, le poids de votre table "pages" sera divisé par 3 au minimum (sur la table que j'ai testé, avec un DS assez léger, le poids a été divisé par 4)
Encore un indice sur l'efficacité de la solution


7. TemplaVoilà est plus lent que d'autres méthodes de templating.

Je me suis amusé à prendre un site développé avec TemplaVoila et a re-mapper la page d'accueil avec un autre système de templating (Jetts pour ne pas le nommer) et les résultats sont intéréssants :
- Lorsque la page est déjà mise en cache, TemplaVoilà s'en sort et est à peine plus lent que Jetts (de l'ordre de quelques millisecondes)
- Lorsque la page n'est pas mise en cache, TemplaVoila s'avère 6% plus lent que Jetts, ce qui est un chiffre qui commence à devenir très intéressant dans le contexte où la page ne peut être mise en cache.

Il m'est arrivé par exemple pour un client de devoir générer une version HTML+PDF de toutes les pages d'un site (pour un système de cache statique assez complexe) toutes les nuits. Ce site faisait 6000 pages en 2 langues, ce qui nous fait en tout 24000 affichage de pages, et croyez moi, dans ce cas, on est bien contents de gagner 6% de temps...

Pour faire mes mesures, j'ai d'abord affiché la page 12 fois de suite en vidant le cache à chaque fois pour les 2 méthodes de templating, j'ai supprimé la mesure la plus élevée et la plus basse pour réduire les erreurs dûes à l'activité de mon ordinateur et j'ai fait la moyenne. Ensuite, j'ai répété l'opération sans vider le cache pour obtenir la deuxième série de résultats.



Il y a encore d'autres raison pour lesquelles vous devriez abandonner TemplaVoilà, ceci n'est pas une liste exhaustive et j'en ai encore quelques unes en tête (juste pour le fun, imaginez la galère si un client vous demandait d'exporter vos contenus vers un autre système avec tout ce xx de XML...)



Pour finir, tordons le cou à quelques idées reçues à propos de TemplaVoila :

- TemplaVoilà me fait gagner du temps :
juste pour info, il m'a fallu 30 minutes pour re-mapper complètement ma page de test avec Jetts, et il me faudrait ensuite quelques secondes pour créer autant de sous template que je le souhaite.
Vous pensez vraiment qu'avec TemplaVoilà vous auriez été plus vite? Il aurait fallu créer la DS, puis sans doute l'éditer à la main (ça finit toujours comme ça) et enfin se taper le mapping du TO, sans compter qu'il faut se taper un "update mapping" > "save and return" à chaque fois que vous faite une modif dans le template HTML (ce qui arrive souvent en début de projet). En même temps, si vous êtes un as des jeux vidéos et que vous avec une souris laser super précise, c'est possible

- TemplaVoilà me permet de créer autant de zones que je le souhaite dans mon BE :
Un classique du rire, sachez seulement que :
- il suffit d'une ligne de TCA et une ligne de Typoscript pour ajouter une nouvelle colonne dans le BE standard
- même les plus gros sites sur lesquels j'ai travaillé (y compris le site d'Accor par exemple) n'ont jamais nécessité plus de 4 colonnes. L'erreur classique étant d'utiliser le BO pour placer des plugins qui ne sont jamais édités, cela bouffe de la place pour rien et perd votre contributeur. Si vous devez mettre un plugin de remontée de news sur votre site, injectez le directement en Typoscript que diable! Votre contributeur ne va pas le modifier tous les jours (en fait, il ne va jamais le modifier)

- TemplaVoila me permet de créer un BE qui ressemble au front :
Youpi... mais ça sert à quoi? Si vous voulez vraiment un BE qui ressemble au front, il serait temps de se tourner vers l'édition front-end, l'extension feeditadvanced en version 1.2 est maintenant assez stable.
Et puis... Vous avez déjà entendu parler des concepts de séparation du fond et de la forme? Vous savez, le fait que le fond est porté par le HTML et la forme par le CSS? Un BE qui ressemble au front, ne briserait-il pas ce concept? C'est le cas de TemplaVoilà, car si vous changez le front (le couple DS/TO dans TemplaVoilà), vos contenus se retrouvent perdu dans la nature (dans la fameuse case "éléments non utilisés"), dans TemplaVoilà, c'est la forme qui guide le fond, un comble!!! (ce point là, aurait pû être une des 7 raisons à part entière)


Allez y faites chauffer les Kalashnikovs, je suis prêt ;-)

Ce message a été modifié par duch - 10/03/2010, 11:15 .