> Pour avoir tâté du SPIP, du Joomla, du eZ Publish ou encore du SilverStripe, aucun n'arrive au même niveau de qualité.
Étrangement, c'est ce que je me disais aussi avant de toucher (sous la pression d'un client) à eZ Publish (4.0). Depuis, je n'ai plus aucune envie de revenir à Drupal. Je m'explique.
J'avais choisi Drupal car (1) il me semblait le plus proche de mes propres choix techniques — traduc' avec gettext, AJAX avec jQuery, gabarits en pur PHP, et (2) car il avait une communauté impressionnante et un nombre de modules tout aussi impressionnant. Cela me semblait le mieux pour me permettre de réaliser les demandes de mes clients au plus vite. Hélas, le passage de la théorie à la pratique fut plutôt difficile.
Tout d'abord, les modules : oui, il y en a beaucoup, mais une bonne partie ne fonctionnent pas avec la dernière version (je ne voulais pas de la 5.x). Je me suis donc trouvé limité dans mes choix. Il y a aussi beaucoup de modules qui procurent des fonctionnalités équivalentes (gestion d'images, par exemple) sans qu'un module-phare se démarque. On se retrouve donc à tester (ça prend du temps) et à faire un choix entre des modules qui ont des avantages et des défauts (pour reprendre l'exemple des images, certains modules les gèrent comme des nœuds Drupal, mais ne permettent pas de les positionner comme on veut dans le document, d'autres le permettent, mais elles sont alors considérées comme des simples fichiers dissociés de la gestion de contenu. Aucune de ces solutions n'est satisfaisante). L'intégration entre modules pèche un peu aussi (par exemple l'intégration entre les gestionnaires d'images et les éditeurs WYSIWYG). C'est un joyeux bordel, et même avec des sites comme [http://drupalmodules.com/] on ne s' y retrouve pas des masses.
L'autre gros point noir à mon sens est la personnalisation. Vous allez me dire : comment ça ? Il y a des CSS, des gabarits, des /callbacks/ pour chaque thème, c'est très personnalisable ! Eh ben, pas vraiment. Tout d'abord, le choix a été fait d'envoyer aux gabarits des variables contenant du code HTML préalablement généré. Il aurait été à mon sens beaucoup plus efficace d'envoyer aux gabarits des tableaux associatifs PHP avec les contenus bruts, et laisser la génération du HTML dans ces derniers. Faute de cela, on se retrouve à aller bidouiller son fichier template.php et rajouter /callback/ sur /callback/ pour faire correspondre l'affichage à ce que l'on souhaite. C'est compliqué, et peu intuitif.
Il y a aussi le cas où les informations que l'on veut ne sont tout simplement pas fournies. Un exemple simple : je voulais un bloc affichant les autres pages ayant le même terme de taxonomie. Il a fallu pour cela utiliser le module Views, et fabriquer une vue compliquée avec du code PHP (et je n'ai toujours pas trouvé comment éliminer de la liste la page courante !), modifier les paramètres du bloc lié à la vue pour définir où il s'affichait, etc. De la même manière, avoir un ordre d'affichage personnalisé des contenus dans une catégorie nécessite un module spécial (nodeorder) qui remplace les pages de taxonomie (j'ai mis un bout de temps à comprendre que les liens créés via Pathauto pointaient toujours vers le module standard). Certains modules, aussi, n'ont pas de /callbacks/ pour appliquer un thème. J'ai souvenir d'avoir dû créer une copie du module Blog pour lui rajouter les /callbacks/ dont j'avais besoin. Au final, cela demande beaucoup de travail et l'utilisation de systèmes disparates pour arriver à ses fins.
Et j'en viens donc à eZ Publish. Au départ, je n'en voulais pas parce que (1) c'était moins communautaire, et (2) cela semblait être une grosse usine à gaz. Ayant dû m'y mettre, je constate que, si c'est *bien* une usine à gaz (avec un particulier un langage de gabarit à la Smarty absolument inutile et énervant, ainsi qu'un nombre incalculable de fichiers de configuration), il a des atouts importants pour un intégrateur de sites.
La souplesse de modification, d'abord. Tout (ou presque) se passe dans les gabarits. Les données brutes sont accessibles au langage de gabarit, et on peut récupérer (via l'opérateur fetch) du contenu supplémentaire à peu près sans limites. Certes, cela enlève un peu à mon sens la séparation nette entre la logique métier et la logique de présentation, mais je préfère cent fois cela à devoir /forker/ un module Drupal pour arriver au même résultat (en particulier lorsque le client veut la modif' pour avant-hier :-) L'architecture globale est par ailleurs bien plus propre à mon sens, avec une orientation objet très prononcée, et cela rend l'écriture d'extensions (si le besoin s'en fait sentir) plus agréable.
Le principe de classes de documents dynamiques est aussi très bon. La classe d'article standard ne vous plaît pas parce qu'il vous faut un « châpo » et une note pour les tests ? Quelques clics plus tard vous avez les attributs nécessaires dedans, et ils sont accessibles dans les gabarits pour être affichés comme on le souhaite. Vous avez besoin de rajouter des encadrés ? Déclarez la classe comme conteneur, et créez des éléments fils avec une classe spécifique, puis faites le fetch qui va bien dans le gabarit. Les formulaires sont pareillement plutôt aisés à créer (il faut néanmoins modifier des fichiers ini, hélas) et les images, fichiers, vidéos, etc. sont gérés comme des documents standard, avec gestion des versions, liens dynamiques, etc. à la clé.
Enfin, j'ai apprécié l'idée de stocker les textes dans du XML. Ceci permet d'empêcher l'utilisateur de faire n'importe quoi avec la charte graphique (je vous dis pas le plaisir que ça fait de voir l'esthétique de votre site flanquée en l'air par un ahuri amateur de Comic Sans MS) tout en lui laissant une certaine flexibilité par le biais de balises personnalisées dont vous pouvez décider l'apparence par un gabarit /ad hoc/. Depuis quelque temps, l'éditeur XML utilisé est basé sur TinyMCE ; l'ergonomie est donc tout à fait acceptable (personnellement, j'aurais bien sûr préferé un WYMeditor, mais pour l'avoir testé, je pense pouvoir dire qu'il est loin d'être mûr pour une utilisation en production).
En conclusion, le choix du CMS dépend bien entendu de l'approche de chacun (certains préfèreront peut-être même un SPIP pour sa simplicité) mais si votre but est d'avoir la plus grande flexibilité pour vos développements, je vous suggère de jeter un œil à eZ Publish. En revanche, n'espérez pas pouvoir l'appréhender en quelques instants : à l'instar de Drupal, sa courbe d'apprentissage est plutôt rude, et la documentation ne donne pas toutes les infos utiles, loin s'en faut. Google vous sera un ami *très* précieux dans cette aventure...
Quelques liens rapides pour terminer (pardonnez-moi au passage pour la longueur inconsidérée de ce message et ses passages très « 3615 MAVIE ») :
[^] # Re: Rien ne l'arrête
Posté par William Steve Applegate . En réponse à la dépêche Entretien avec Dries Buytaert, le créateur de Drupal. Évalué à 2.
Étrangement, c'est ce que je me disais aussi avant de toucher (sous la pression d'un client) à eZ Publish (4.0). Depuis, je n'ai plus aucune envie de revenir à Drupal. Je m'explique.
J'avais choisi Drupal car (1) il me semblait le plus proche de mes propres choix techniques — traduc' avec gettext, AJAX avec jQuery, gabarits en pur PHP, et (2) car il avait une communauté impressionnante et un nombre de modules tout aussi impressionnant. Cela me semblait le mieux pour me permettre de réaliser les demandes de mes clients au plus vite. Hélas, le passage de la théorie à la pratique fut plutôt difficile.
Tout d'abord, les modules : oui, il y en a beaucoup, mais une bonne partie ne fonctionnent pas avec la dernière version (je ne voulais pas de la 5.x). Je me suis donc trouvé limité dans mes choix. Il y a aussi beaucoup de modules qui procurent des fonctionnalités équivalentes (gestion d'images, par exemple) sans qu'un module-phare se démarque. On se retrouve donc à tester (ça prend du temps) et à faire un choix entre des modules qui ont des avantages et des défauts (pour reprendre l'exemple des images, certains modules les gèrent comme des nœuds Drupal, mais ne permettent pas de les positionner comme on veut dans le document, d'autres le permettent, mais elles sont alors considérées comme des simples fichiers dissociés de la gestion de contenu. Aucune de ces solutions n'est satisfaisante). L'intégration entre modules pèche un peu aussi (par exemple l'intégration entre les gestionnaires d'images et les éditeurs WYSIWYG). C'est un joyeux bordel, et même avec des sites comme [http://drupalmodules.com/] on ne s' y retrouve pas des masses.
L'autre gros point noir à mon sens est la personnalisation. Vous allez me dire : comment ça ? Il y a des CSS, des gabarits, des /callbacks/ pour chaque thème, c'est très personnalisable ! Eh ben, pas vraiment. Tout d'abord, le choix a été fait d'envoyer aux gabarits des variables contenant du code HTML préalablement généré. Il aurait été à mon sens beaucoup plus efficace d'envoyer aux gabarits des tableaux associatifs PHP avec les contenus bruts, et laisser la génération du HTML dans ces derniers. Faute de cela, on se retrouve à aller bidouiller son fichier template.php et rajouter /callback/ sur /callback/ pour faire correspondre l'affichage à ce que l'on souhaite. C'est compliqué, et peu intuitif.
Il y a aussi le cas où les informations que l'on veut ne sont tout simplement pas fournies. Un exemple simple : je voulais un bloc affichant les autres pages ayant le même terme de taxonomie. Il a fallu pour cela utiliser le module Views, et fabriquer une vue compliquée avec du code PHP (et je n'ai toujours pas trouvé comment éliminer de la liste la page courante !), modifier les paramètres du bloc lié à la vue pour définir où il s'affichait, etc. De la même manière, avoir un ordre d'affichage personnalisé des contenus dans une catégorie nécessite un module spécial (nodeorder) qui remplace les pages de taxonomie (j'ai mis un bout de temps à comprendre que les liens créés via Pathauto pointaient toujours vers le module standard). Certains modules, aussi, n'ont pas de /callbacks/ pour appliquer un thème. J'ai souvenir d'avoir dû créer une copie du module Blog pour lui rajouter les /callbacks/ dont j'avais besoin. Au final, cela demande beaucoup de travail et l'utilisation de systèmes disparates pour arriver à ses fins.
Et j'en viens donc à eZ Publish. Au départ, je n'en voulais pas parce que (1) c'était moins communautaire, et (2) cela semblait être une grosse usine à gaz. Ayant dû m'y mettre, je constate que, si c'est *bien* une usine à gaz (avec un particulier un langage de gabarit à la Smarty absolument inutile et énervant, ainsi qu'un nombre incalculable de fichiers de configuration), il a des atouts importants pour un intégrateur de sites.
La souplesse de modification, d'abord. Tout (ou presque) se passe dans les gabarits. Les données brutes sont accessibles au langage de gabarit, et on peut récupérer (via l'opérateur fetch) du contenu supplémentaire à peu près sans limites. Certes, cela enlève un peu à mon sens la séparation nette entre la logique métier et la logique de présentation, mais je préfère cent fois cela à devoir /forker/ un module Drupal pour arriver au même résultat (en particulier lorsque le client veut la modif' pour avant-hier :-) L'architecture globale est par ailleurs bien plus propre à mon sens, avec une orientation objet très prononcée, et cela rend l'écriture d'extensions (si le besoin s'en fait sentir) plus agréable.
Le principe de classes de documents dynamiques est aussi très bon. La classe d'article standard ne vous plaît pas parce qu'il vous faut un « châpo » et une note pour les tests ? Quelques clics plus tard vous avez les attributs nécessaires dedans, et ils sont accessibles dans les gabarits pour être affichés comme on le souhaite. Vous avez besoin de rajouter des encadrés ? Déclarez la classe comme conteneur, et créez des éléments fils avec une classe spécifique, puis faites le fetch qui va bien dans le gabarit. Les formulaires sont pareillement plutôt aisés à créer (il faut néanmoins modifier des fichiers ini, hélas) et les images, fichiers, vidéos, etc. sont gérés comme des documents standard, avec gestion des versions, liens dynamiques, etc. à la clé.
Enfin, j'ai apprécié l'idée de stocker les textes dans du XML. Ceci permet d'empêcher l'utilisateur de faire n'importe quoi avec la charte graphique (je vous dis pas le plaisir que ça fait de voir l'esthétique de votre site flanquée en l'air par un ahuri amateur de Comic Sans MS) tout en lui laissant une certaine flexibilité par le biais de balises personnalisées dont vous pouvez décider l'apparence par un gabarit /ad hoc/. Depuis quelque temps, l'éditeur XML utilisé est basé sur TinyMCE ; l'ergonomie est donc tout à fait acceptable (personnellement, j'aurais bien sûr préferé un WYMeditor, mais pour l'avoir testé, je pense pouvoir dire qu'il est loin d'être mûr pour une utilisation en production).
En conclusion, le choix du CMS dépend bien entendu de l'approche de chacun (certains préfèreront peut-être même un SPIP pour sa simplicité) mais si votre but est d'avoir la plus grande flexibilité pour vos développements, je vous suggère de jeter un œil à eZ Publish. En revanche, n'espérez pas pouvoir l'appréhender en quelques instants : à l'instar de Drupal, sa courbe d'apprentissage est plutôt rude, et la documentation ne donne pas toutes les infos utiles, loin s'en faut. Google vous sera un ami *très* précieux dans cette aventure...
Quelques liens rapides pour terminer (pardonnez-moi au passage pour la longueur inconsidérée de ce message et ses passages très « 3615 MAVIE ») :
- La doc officielle [http://ez.no/doc/]
- L'ancienne doc, plus maintenue, mais parfois plus explicite que le /Technical Manual/ : [http://ez.no/ezpublish/documentation/toc]
- Un wiki avec des infos intéressantes : [http://ezpedia.org/wiki/en/ez]
- Le blog de Pwet : [http://pwet.fr/tags/keywords/weblog/ez_publish]
- Un autre blog qui m'a été utile : [http://serwatka.net/blog/]
Bonne découverte.
Envoyé depuis mon PDP 11/70