[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) :

-------------------------------------------------------------------------------
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 mars 2010 à 11:17.

[Laogan]

Moi j'ai pas envie de me lancer dans un débat en fin de compte stérile parce que je suis conscient des lacunes de templavoila, je ne dirais qu'une chose, templavoila m'a permis de créer des Back Office digne de ce nom pour mes rédacteurs, et de me sentir plus à l'aise commercialement parlant avec des BO qui ont de la gueule.

Certe, techniquement le choix se discute, et je suis d'accord sur les performances, mais d'un point de vue contributeurs, vous savez les gens qui ne comprennent rien au technique... ben c'est juste beaucoup mieux... Pour que TYPO3 se développe, il faut qu'il devienne plus simple et attractif dans le BO, et même si templavoila est une usine à gaz, en fin de compte c'est ce qu'il permet de faire.

De plus je vais bientôt sortir une extension compatible uniquement avec Templavoila et qui permettra de :
- limiter les contenus en fonction des zones dans lesquelles ils sont créés et du niveau d'arborescence,
- limiter les glisser déposer en fonction des zones prévues pour,
- limiter les copier/coller et couper/coller en fonction des zones prévues pour,
- avoir un aperçu plus clair des contenus et des FCEs créés dans les pages.

Ainsi nous n'aurons plus à dire aux contributeurs "oui vous pouvez faire des glisser déposer mais pas ici', ou alors "oui vous pouvez faire des copier coller mais pas là", ou encore "ce contenu il n'est pas prévu pour cette zone". Et tout ça configurable en typoscript dans le TSconfig des pages.

[Popy]

Trooolllliiiinnnnnng !

Perso, je retiens principalement le coup des problèmes de maintenance, qui est la chose qui me retiens le plus d'essayer TV sur un projet sérieux.
Sinon, pour la qualité du code, de toutes façons, tout Typo est codé avec les pieds (et venez pas me parler de la 4.3, j'en lol d'avance).

On retiendra surtout la nouvelle alternative : Jetts

[duch]

Popy dit :

Trooolllliiiinnnnnng !
...
On retiendra surtout la nouvelle alternative : Jetts

Nope, c'est pas du trolling, et je n'essaie pas du tout de pousser Jetts.
Ces remarques restent valables lorsqu'on utilise automaketemplate ou même la bonne vieille méthode des marqueurs.
Je suis par contre irrité, c'est vrai, de constater à quel point une extension aussi bancale que TemplaVoilà est mise en avant

Laogan dit :

Moi j'ai pas envie de me lancer dans un débat en fin de compte stérile

Je ne suis pas sûr que ce débat soit aussi stérile que ça. Tout dépend de l'attente des clients.

Mes clients (qui sont en général des grands comptes) attendent de leur CMS :

- qu'il soit rapide
- qu'il soit évolutif et donc qu'on puisse ajouter au fur et à mesure de nouvelles fonctions imprévues et ce quelque soit la structure des contenus (l'indépendance entre fond et forme est donc primordiale)
- que les contenus puissent être exportables vers n'importe quel autre plate-forme
- que la maintenance soit aisée

À mon sens, et comme je pense l'avoir démontré, TemplaVoilà ne répond pas à ces contraintes.

Laogan dit :

De plus je vais bientôt sortir une extension compatible uniquement avec Templavoila et qui permettra de :

Tu m'a montré ta nouvelle extension et franchement elle est très bien. Elle comble une des grosses lacunes de Typo3 et je la conseillerais volontiers aux gens qui utilisent TemplaVoilà quand elle sera sortie.

Mais sache qu'avec le module standard de Typo3 on peut faire la même chose (en moins sexy, c'est vrai, mais en plus simple) via un hook dans tcemainprocdm.
Il suffit pour cela de tester le champ colPos de l'enregistrement déplacé (ou inséré) dans la méthode processCmdmap_preProcess et de renvoyer un message d'erreur si il ne peut pas être crée dans cette zone.
La même technique peut même être utilisée pour empêcher un utilisateur de supprimer un enregistrement dans une zone donnée.
Et encore une fois, c'est plus simple à réaliser car ce sont des méthodes intégrées à Typo3 (un point de plus pour moi).

Ce message a été modifié par duch - 22 février 2010 à 11:11.

[friteuseb]

Je plusoie sur le thème de l'accessibilité backend pour les utilisateurs.
Quand tu as un design morcelé avec de nombreuses zones, ajouter des colonnes ne donne pas toujours un résultat très pratique.

Autre chose aussi, pour un client, l'interet d'utiliser de l'open source, c'est aussi de ne pas etre pieds et poings lié avec un opérateur technique, et dans le cas d'un système de templating original, que se passe t'il si ils doivent changer de prestataire ?

Sinon pour les points techniques, tu es juste, mais je dirais que c'est plutot notre problème que celui du client, et comme le but est tout de meme de les servir au mieux, je préfère en chier de mon côté et leur fournir un site agréable à utiliser.

[duch]

friteuseb dit :

Autre chose aussi, pour un client, l'interet d'utiliser de l'open source, c'est aussi de ne pas etre pieds et poings lié avec un opérateur technique, et dans le cas d'un système de templating original, que se passe t'il si ils doivent changer de prestataire ?

Comme je le disais plus haut, il ne s'agit pas ici de comparer Jetts à TemplaVoilà, donc si ton client ne souhaite pas utiliser un système original (qui n'a rien de très original d'ailleurs puisque c'est le seul qui se base sur des standards du web), il peut en choisir un autre et ne pas être pieds et poings liés avec un prestataire.

L'avantage de l'open-source, c'est aussi de pouvoir avancer, de proposer de nouvelles choses, et de ne pas rester scotché avec des solutions bancales .

friteuseb dit :

Sinon pour les points techniques, tu es juste, mais je dirais que c'est plutot notre problème que celui du client, et comme le but est tout de meme de les servir au mieux, je préfère en chier de mon côté et leur fournir un site agréable à utiliser.

Je ne suis pas d'accord avec toi pour dire que les problèmes techniques ne sont que notre problème, si ton client se retrouve avec un site jetable (ça arrive souvent) et non évolutif, ça deviendra son problème, et c'est notre travail d'éviter ça.

Combien de fois ai-je entendu cette phrase? : "bonjour monsieur, je viens vous voir avec mon site qui a été fait par une autre agence et en fait on aimerait changer le design, mais on peut pas car tout a été fait avec de FCEs (c'est ce qu'ils m'ont dit), et il faut changer tous les flexforms du site (c'est quoi un flexform dites? )"

[Popy]

De toutes façons, à partir du moment ou c'est basé sur XML, ça commence a ressembler à un travail de peintre.

(twoll inside)

[duch]

Popy, le 22/02/2010, 11:23, dit :

De toutes façons, à partir du moment ou c'est basé sur XML, ça commence a ressembler à un travail de peintre.

(twoll inside)

Effectivement, avec des interventions comme celles-ci, ça va pas faire avancer le débat

mais sinon, sur le fond, tu n'a pas tort

[team17]

J'utilise TV depuis 5 bonnes années, après avoir travaillé avec automake et template selector.
Templavoilà m'a apporté beaucoup de facilité pour développer de nouveaux sites... Au début, ce que j'ai apprécié, c'est le gain de temps apporté pour créer un site et puis surtout l'interface de mapping. Tout se fait de visu, c'est cool. On a aussi les FCE quand on veut pas trop se prendre la tête. On peut créer des formulaire adaptés et le design vient tout autour comme par magie !

Et puis, au fil du temps, on s'aperçoit des bogues récurrents comme par exemple le mapping qui ne passe pas ou bien, ça m'est arrivé, le texte de mes RTE qui est zappé dans les FCE. C'est un apprentissage tout ça et avec la pratique, on repère vite les problèmes et on sait comment y remédier... par contre, expliquez ça à quelqu'un (un stagiaire ?) qui découvre TYPO3 et qui doit repasser derrière vous... En plus, on va pas trop le crier sur les toits. Y a aussi le problème où l'on modifie les DS... attention à ne pas écraser tout le boulot si on regénère les gabarits.

Alors, c'est vrai que TV c'est bien pratique mais au fil du temps, on ne soucie plus trop de tout ça, on fait des sites et ça marche.... et puis il n'y avait pas d'alternatives valables... depuis peu. Alors, si l'on commence à parler des perfs de Templavoilà, de ces 25000 lignes de code, ça ne joue pas trop en faveur de TYPO3. C'est déjà un système assez lourd qui demande un hébergement adapté.... Perso, c'est ce qui me fâche avec TYPO3 et c'est ce qui me fait tourner vers d'autres systèmes plus légers comme MODx.

Concernant le coté agréable du back office, heureusement que TYPO3 ne se limite pas à des colonnes ou des FCE. C'est toute la logique de TYPO3 qu'un rédacteur doit assimiler (création d'enregistrements dans un sysfolder, etc.) et le système de templating n'agit que sur une partie infime.

Enfin, sur le dialogue avec le client, c'est vrai qu'il veut un site qui fonctionne et facilement administrable. C'est peut-être bien aussi de fournir un système optimisé, parce qu'un goulot d'étranglement à un niveau fait perdre les gains de performance remportés à d'autres endroits (dans le développement d'extensions par ex), non ? Je relativise quand même sur l'affichage des pages grâce au cache de TYPO3 mais quand même...

Si je peux trouver une alternative simple, performante et qui réponde autant à mes besoins qu'avec TV, alors, c'est clair que je l'étudierai...

Merci Duch pour cette analyse détaillée qui fait réfléchir

/team

[Oom Paul]

je suis d'accord avec Team17, merci Duch pour ce débat riche et intéressant.

[Popy]

'tain ça en deviens impossible de troller sur ce forum.

[duch]

Je plussoie dans le sens de Team.

Faites travailler votre mémoire et vous verrez que la facilité dont il est souvent fait mention avec TemplaVoilà cache une forêt de petits bugs gênants. Qui n'a jamais perdu un mapping complet comme ça sans raison? Qui n'a jamais eu le message "no content found" sur une div après avoir fait un "save and return" (mieux, une fois sur un template, j'avais une div différente qui sautait à chaque enregistrement)?

Bien souvent, on a oublié toutes les petites choses qu'on a dû intégrer pour contourner les bugs de TemplaVoilà et on a retenu que l'apparente facilité, mais, comme le dit Team, mettez un débutant sur le mapping d'un template un peu compliqué, laissez le mariner quelques heures et revenez pour voir dans quel état il est, ça risque de vous faire relativiser...

[Oom Paul]

de toute façon, le templating sur un CMS c'est ni pour un client, ni pour un débutant... c'est un peu comme la conduite sur glace, c'est pas pour un jeune conducteur (sauf Popy, et encore, l'est plus tout jeune).

[waloukern]

En tant que petit scarabée sur TYPO3, et n'ayant réalisé que des petits sites, TV est ce que j'ai trouvé de plus simple (faut avouer que je n'ai pas encore regardé Jetts).

[Popy]

Je guette mes premiers cheveux blancs !

[Yucky]

Pour n'être ni pro ni anti TV, je trouve que les deux gros avantages de TV c'est le rendu backend, car même si le but du CMS est de séparer le fond et la forme, ce que veulent les clients c'est la forme dans le backend, et les FCE qui évitent le développement d'extension pour la mise en place d'éléments simple (comme le caroussel sur cette page d'accueil qui permet d'insérer vidéos et / ou images : www.opera-lyon.com)...

Par contre la simplicité est vraiment relative...
La méthode la plus simple pour intégrer un site et qui demande le moins de compétences en TS c'est de mettre ses marqueurs "à la main" dans son template ou avec automaketemplate, quoi qu'on dise c'est LA méthode la plus simple.
Parce que pour avoir monté un site complexe avec TV je peux vous dire que côté configuration du XML, typoscript et simplification pour l'utilisateur, c'est beaucoup plus compliqué avec TV et cela demande des compétences bien plus importantes en TS.... (surtout quand on considère que le client peut tout faire où il veut et comme il veut).

[Apen]

Comme tout le monde ici, j'utilise TV que pour la mise en forme du backend (une priorité pour nos clients) et la gestion des "flexible content". Personnellement, je ne suis pas plus attaché que cela à cet outil et si je peux faire la même chose sans de nombreuses couches inutiles, je prends!

Je devrais jeter un coup d'œil à Jetts :-)

En tout cas, très intéressant ce bench.

Ce message a été modifié par Apen - 23 février 2010 à 12:40.

[duch]

Ouah! alors là les enfants je dois avouer que je suis sur le cul et que je ne m'attendais pas à ce que cette discussion tourne de cette façon (je pensais me faire étriper virtuellement à vrai dire).

Je pensais qu'il y avait quand même parmi vous des gens qui étaient convaincus par TemplaVoilà et qui l'utilisaient par réel choix (mais où est King76?!?). Or il semble qu'il n'en soit rien et que tous ceux qui se sont exprimés ici, sans exception, l'utilisent par dépit; faute de mieux.

Là, je dois avouer que ça me laisse bouche bée. Bouche bée car, si aucun de vous n'est convaincu, ça veux dire que ça doit être à peu près la même chose pour le reste de Typoteurs de cette planète. Comment se fait-il donc que tout le monde utilise un système d'extension qui ne convaint personne? On parle d'open-source là où est passé votre libre arbitre? (comment ça j'en fait trop?)

Le monde Typo3 serait-il atteint par le phénomène windows?


Bon, je vais me servir un petit rhum et méditer sur le monde moi, j'en ai bien besoin, tout fout le camp ma pauvre dame...

Ce message a été modifié par duch - 23 février 2010 à 17:10.

[Laogan]

Ha je suis pas d'accord, on ne dis pas qu'on est pas convaincu, mais que l'on reste ouvert à d'autres solutions .

[rakel]

duch, le 23/02/2010, 17:05, dit :

Ouah! alors là les enfants je dois avouer que je suis sur le cul et que je ne m'attendais pas à ce que cette discussion tourne de cette façon (je pensais me faire étriper virtuellement à vrai dire).

t'inquiète duch, c'est juste que j'ai pas le temps ! sinon le coeur y est
une autre fois peut être

[duch]

Laogan, le 23/02/2010, 17:12, dit :

Ha je suis pas d'accord, on ne dis pas qu'on est pas convaincu, mais que l'on reste ouvert à d'autres solutions .

Tu semble être le plus convaincu de tous (alors que quand on s'est connus, tu étais encore sain d'esprit, snif ) et pourtant, je te cite, tu dis que "tu es conscient des lacunes de templavoila", en terme de conviction on a vu mieux

rakel, le 23/02/2010, 17:14, dit :

duch, le 23/02/2010, 17:05, dit :

Ouah! alors là les enfants je dois avouer que je suis sur le cul et que je ne m'attendais pas à ce que cette discussion tourne de cette façon (je pensais me faire étriper virtuellement à vrai dire).

t'inquiète duch, c'est juste que j'ai pas le temps ! sinon le coeur y est
une autre fois peut être

Ouf, ça me rassure.

[friteuseb]

En fait pour moi c'est clairement la bonne méthode, mais la réalisation est franchement pas finie.
Il manque des moyens d'organiser les FCE, de gèrer les droits de création de FCE par zones, et surtout tout ses problèmes d'enregistrement, de pertes d'infos, de bugs d'imports etc...

Il ya AOE media qui a crée une extension qui semble palier à la plupart des besoins d'organisation, mais elle n'a pas été reversée à la communauté pour l'instant.

[duch]

friteuseb, le 23/02/2010, 19:13, dit :

En fait pour moi c'est clairement la bonne méthode, mais la réalisation est franchement pas finie.
Il manque des moyens d'organiser les FCE, de gèrer les droits de création de FCE par zones, et surtout tout ses problèmes d'enregistrement, de pertes d'infos, de bugs d'imports etc...

Il ya AOE media qui a crée une extension qui semble palier à la plupart des besoins d'organisation, mais elle n'a pas été reversée à la communauté pour l'instant.

Ne me fait pas dire ce que je n'ai pas dis Frite. Je ne remet pas en cause le concept de TemplaVoilà mais la réalisation technique.

L'idée initiale de pouvoir mapper un template sans connaissances particulières en utilisant du point and click est séduisante, mais comme tout le monde s'accorde à le dire, elle masque une forêt de complexité qui fait que TemplaVoilà n'y répond tout simplement pas au final.

Même si au final le BO est peut-être plus agréable pour le client (ce point est AMHA fort discutable), l'objet de ce bench est de démontrer que les conséquences pour y arriver en terme de qualité du produit finit (réelle, pas apparente) et de maintenabilité sont insupportables pour ces mêmes clients.

Laogan, le 22/02/2010, 10:32, dit :

De plus je vais bientôt sortir une extension compatible uniquement avec Templavoila et qui permettra de :
- limiter les contenus en fonction des zones dans lesquelles ils sont créés et du niveau d'arborescence,
- limiter les glisser déposer en fonction des zones prévues pour,
- limiter les copier/coller et couper/coller en fonction des zones prévues pour,
- avoir un aperçu plus clair des contenus et des FCEs créés dans les pages.

Ainsi nous n'aurons plus à dire aux contributeurs "oui vous pouvez faire des glisser déposer mais pas ici', ou alors "oui vous pouvez faire des copier coller mais pas là", ou encore "ce contenu il n'est pas prévu pour cette zone". Et tout ça configurable en typoscript dans le TSconfig des pages.

Je sens que tu va me tuer, mais histoire d'apporter encore un peu d'eau à mon moulin, je me suis amusé à refaire un système similaire à celui que tu décris au niveau des autorisations, histoire de voir en combien de lignes c'était faisable lorsqu'on utilisait pas TemplaVoilà mais la méthode standard...

verdict :

J'ai fait ça en 100 lignes de code et 2 hooks (un sur processCmdmap_preProcess et l'autre sur processDatamap_postProcessFieldArray) et bien sûr aucune XCLASS.
Je pense qu'avec TemplaVoilà le travail à dû être bien plus long et conséquent, et je salue de ce fait ton courage (mais je peux me tromper)

Cette nouvelle fonction sortira avec la version 2.1 de Jetts (demain sans doute)

Ce message a été modifié par duch - 24 février 2010 à 10:39.

[duch]

Une 8ème bonne raison (enfin 10ème si on cherche entre les lignes) : Dmitry Dulepov, l'inventeur de TemplaVoilà a décidé d'abandonner la tête du projet car il n'était plus en phase avec la manière dont il évoluait (pour utiliser un doux euphémisme).

Les sources :

http://forum.typo3.f...showtopic=15206
http://dmitry-dulepo...emplavoila.html

Ce message a été modifié par duch - 04 mars 2010 à 12:08.

[Popy]

Ca pourrait être positif !