Mais l’argument du client autonome est éloigné de la réalité. En effet, ce billet ne parle pas vraiment des « flexform ». Ni du fait que presque tout les champs de tous les formulaires peuvent-être renommé, caché, forcé…
Aussi le gestionnaire de news (tt_news) peut apparaitre comme « Ajouter un cv » sur uen page et « Ajouter une brève » sur une autre, avec des champs différent et sans aucune ligne de code php, sans aucun champs en plus dans la base etc…

Evidemment il est compliqué d’expliquer cette capacité sans montrer d’exemple. Mais au final l’interface client sous typo3 est bien plus sobre et épurée, elle « parle » mieux au client, si le client hésite une fois sur un champs, on ajoute un commentaire après le nom…

Bref, je n’ai pas trouvé d’autres CMS avec cette capacité (je peux me tromper cependant) :
Faire avec du générique (gain côté développement/nombre de plug-in/import-export…) des interfaces spécialisées (ergonomie, simplicité…)

PS : J’ai déjà fait des menus très compliqués en typoscript. Mais une extention php m’aurait pris moins de temps. Je pense qu’il faut réserver typoscript aux actions « simples »

Je me bats depuis des années pour adapter SPIP aux demandes de mes clients. Avec Typo3 c’est possible et pas si compliqué si on accepte de passer la barre de l’apprentissage du TS qui pour ma part vaut le coup !

Derrière cette montagne non insurmontable se cache un océan de liberté

[[ C’est justement un avantage de pouvoir modifier une partie du code HTML dynamiquement en l’ayant dans un fichier de configuration comme le TS que de le chercher dans le HTML et le PHP. ]]

Je pense que ça va rester kif-kif Typo3/Drupal, ça ne me convainc pas. La séparation MVC de Drupal est assez bien faite pour ne pas avoir besoin de chercher trop trop; à la limite je dirais qu’un grep dans un répertoire va plus vite que de parcourir des menus, mais je sais qu’un tel argument va pas convaincre bien des gens

[[le client qui veut être autonome, je trouve qu’il est plus facile de lui demander de modifier une constante dans l’interface de TYPO3 que d’aller fouiller dans du code PHP.]]

Le client qui veut être autonome, on lui fait une vraie interface de configuration personnalisée, n’est-ce pas? parce que la journée où il change quelque chose par erreur et appelle avec son diagnostique « ça marche pus », on est pas plus avancés.

[[Tous les CMS se valent, mais pour ma part, je ne regrette pas d’avoir fait l’effort d’apprendre le Typoscript et si je devais recommencer, je prendrais cette voix.]]

Je dirais plutôt qu’on échange présentement sur deux CMS dans le Top 3. Dans la plupart des cas, on se retrouve pris dans une situation où pour arriver à quoi que ce soit, il faut aller modifier le code directement (des patchs que les concepteurs appellent des « modules »), ce qui brise le cycle des mises à jour. À moins d’avoir un besoin très précis rempli très précisément par un CMS donné, il faut apprendre un engin. Bien qu’il faille apprendre TS pour harnacher Typo3, je ne cacherai pas qu’il faut investir du temps dans Drupal pour apprendre comment l’adapter à sa… euh… vision.

[[Zéro ligne pour construire un menu ca ne se peut pas]]

Je comptais pas le temps pour remplir le formulaire et ordonner ça avec du drag-n-drop! Sérieusement, état actif : déjà géré par Drupal. Sous-pages déployées : déjà géré par Drupal. Mettre en évidence une page externe : un sélecteur CSS de type a[href^="http"] suffit pour n’importe quel navigateur moderne. Pour supporter MSIE6, une quinzaine de lignes copiées/collées du site de drupal (premier hit quand on cherche « menu id »). Faudra donc expliciter le « etc. »

[[J’ai juste hate de voir comment on fait pour gérer un site avec 1000 ou 3000 pages dans Drupal]]

whitehouse.gov est capable. theonion.com aussi. Rendu là, je pense que ça passe le test.

Je gère une installation multi-site (±150) de Drupal, avec un seul codebase, des contenus distincts, des utilisateurs distincts (qui sont « admin » au niveau granulaire où je le permets), et ça a été relativement aisé à déployer, le plus long est le travail d’analyse pour décider de ce qui doit être partagé intra-site ou non. Alors, ça scale aussi dans cette direction-là, si la question venait à se poser!

Ayé la guerre de cloché commence

- Pour ce qui est de l’entremelage entre le code HTML et le reste, je préfère nettement que celui se retrouve dans un fichier de configuration comme le Typoscript que dans un gabarit html ou une extension PHP. C’est justement un avantage de pouvoir modifier une partie du code HTML dynamiquement en l’ayant dans un fichier de configuration comme le TS que de le chercher dans le HTML et le PHP.

- Tu as tout fait raison, pour le client « Moyen », il nous appele malheureusement, mais peu importe le produit, il appelera quand même. Par contre le client qui veut être autonome, je trouve qu’il est plus facile de lui demander de modifier une constante dans l’interface de TYPO3 que d’aller fouiller dans du code PHP.

- Zéro ligne pour construire un menu ca ne se peut pas, sauf si tu utilises le code par défaut, mais dans ce cas là, autant prendre WordPress si c’est pour faire des sites de 5 pages Moi je pensais à des menus spéciaux du genre :

— Gérer l’etat actif (quand on est sur la page en cours et qu’on veut la mettre en évidence dans le menu)
— Quand on veut mettre en évidence un menu si les sous pages sont déployées
— Si on veut mettre en évidence une page externe dans un menu
etc..

Mon « pitch de vente » comme il dit, il tend à démontrer que dans le monde professionnel ou je travail, c’est bien plus pratique d’avoir un outil flexible comme TYPO3. C’est certain qu’a connaissance égal, je suis sur que tu irais aussi vite qu’un gars qui connait TYPO3 sur le bout de doigts. Tous les CMS se valent, mais pour ma part, je ne regrette pas d’avoir fait l’effort d’apprendre le Typoscript et si je devais recommencer, je prendrais cette voix. Le TS est un outil de configuration vraiment très puissant qui m’évite de développer des extensions PHP à tout va ou de gérer des exceptions dans le code PHP.

Et puis les ressources TYPO3 c’est pas çà qui manque, si demain Infoglobe ou tout autres entreprises devaient fermer ses portes, il y en a toujours une derrière pour offrir le support.

D’ailleurs si je veux, je peux changer le comportement d’un menu avec une seule ligne de TS dans une branche d’un site et pour moi c’est vachement pratique

Il faut bien prendre conscience que TYPO3 n’est pas le CMS pour toutes les situations ! Je déconseille TYPO3 pour faire un site perso ou un blogue. Mais si tu as la possibilité de te faire former et d’investir sur du long terme, alors TYPO3 est pour toi ! si tu fais un site de temps en temps, prend WordPress. Et si tu as pas le gout ou pas la possibilité d’investir du temps dans TYPO3, il restera toujours Drupal, mais moi j’ai juste hate de voir comment on fait pour gérer un site avec 1000 ou 3000 pages dans Drupal !

Merci pour tes commentaires, je suis bien ouvert à découvrir les forces de Drupal !

[[ Que ce soit avec WordPress ou Drupal, c’est flagrant quand vous jouer dans vos gabarits HTML, il y a plein de code PHP qui s’entremêlent avec le code HTML. ]]

Et dans votre code TS, y’a plein de code HTML qui s’entremêle avec votre TS

La plupart des éléments nécessaires à construire la page dans Drupal sont accessibles avec une simple déclaration (par exemple $node->title ou $node->body) et ça peut donc demeurer assez propre; du code malpropre, ça se peut dans n’importe quel langage.

[[ D'ailleurs à mon sens un client à plus d’avantages à aller modifier une constante quelque part dans le TS que d’aller jouer dans le code PHP, vous n’êtes pas d’accord ? ]]

Votre client moyen (sauf tout le respect que je lui dois, il paie mon salaire aussi) a de la difficulté à changer la taille des polices dans son navigateur web, vous voudriez qu’il se rende modifier un obscur paramètre au fond d’un menu? Et il va le trouver sans vous? J’ai de la difficulté à croire que votre client ne se jette pas au téléphone pour vous demander de faire la modification à votre place.

[[ TYPO3 aura toujours un pas d’avance sur les autres CMS tant que ces CMS n’auront pas trouvé de solutions équivalentes. ]]

En tout cas, dans Drupal, pour construire un menu, j’ai aussi besoin de moins de 10-15 lignes de code : en fait, zéro

Même si les avantages théoriques de l’esperanto sont énormes vis-à-vis le français, il n’en demeure pas moins que pour discourir en esperanto, faut chercher longtemps un partenaire. Votre « pitch de vente » ne cesse de répéter qu’il faut investir beaucoup de temps pour profiter de TS, eh bien, la journée où la firme qui développe mon site web en Typo3 ferme ses portes, je suis malpris : bien peu de programmeurs vont vouloir investir « plusieurs années » afin de pouvoir modifier un bête CMS.

Et une fois TS su du bout des doigts, je serais surpris de savoir combien de temps de développement est sauvé vs. le temps investi pour développer la même chose sous Drupal.

Voilà mon grain de sel.

Typo (TYPO3 tu voulais dire ?), est moins ouvert que Drupal ! Ca veut dire quoi concrêtement, est ce qu’il faut un ouvre boite pour TYPO3 ?

Plus simple, peut être, WordPress aussi il est plus simple, et c’est pas comme çà qu’on choisi un CMS.

Il nous faut plus d’argument si tu veux que les gens embarque dans ton sens.

A+

Drupal est mieux que Typo, plus simple et plus ouvert.