eZ Publish et la liste de ses vrai / faux défauts
- Publié le 02 Avril 2009
- 11 commentaire(s)
- Catégorie : Technologies Web
“- Comment tu fais un Workflow sur eZ ?
”
- Heu... Tu t'y connais en Multiplexeur ?
- Je vois pas le rapport ?
Un fidèle lecteur a proposé, à l'occasion d'un commentaire, une liste assez classique des défauts et/ou des légèretés d'eZ Publish. En ces temps de polémiques, et en l'absence d'une super idée de code à proposer, j'en profite pour respecter ma promesse et proposer mon point de vue point par point sur cette fameuse liste (en l'état) :
- Le Modèle MVC est assez bizarre vue qu'une partie du contrôleur est dans la template (la partie V)
- Les workflow sont dramatiques
- La boutique est vraiment lourde par rapport aux fonctionnalités proposées
- Le mécanisme de forum fourni de base est assez mauvais. Trop simpliste. Aucune modération prévue de base etc...
- A suivre dans un prochain billet... la liste est encore longue...
Le Modèle MVC est assez bizarre vue qu'une partie du controller est dans la template (la partie V)
Effectivement, les opérateurs de templates de type fetch par exemple contiennent des appels de données normalement positionnés dans la couche "contrôleur" du MVC. L'utilisation du MVC sur eZ Publish reste possible sur une pure utilisation de l'API en mode FrameWork, avec par exemple la constitution de modules. Il devient alors possible de bien segmenter le code avec les appels fetch et les traitements côté PHP, pour exploiter uniquement les templates dans une logique de vue.
Cependant l'exploitation la plus courante reste celle orienté CMS, ou ils serait malvenu de devoir utiliser du PHP pour simplement afficher ses contenus, comme sur n'importe quel autre CMS. Tout les développeurs apprécient les infinies possibilités et la productivité que permet ce mécanisme de fetch "tout en un", qui différencie clairement eZ Publish des autres CMS, et il serait malvenu de basculer soit exclusivement du côté CMS (avec un appauvrissement fonctionnel), soit exclusivement du côté FrameWork. C'est pourquoi eZ Publish se positionne entre le FrameWork et le CMS, à savoir un CMF (Content Management FrameWork)... et jusqu'ici on y trouve notre compte.
Les workflow sont dramatiques
Hélas "dramatiques" et même inexploitables dans de nombreux cas. Avant la version 4.1 et les Object States, il était nécessaire de bricoler entre :
- Se passer des WorkFlow (utilisation des notifications, modération à posteriori)
- Utiliser l'extension eZApprove 2 qui permet de gérer de nombreuses problématiques, mais qui reste inapproprié sur les logiques arborescentes (soumettre un arbre de noeud à modération), et qui contient de nombreux bugs
- Utiliser l'arbre de contenu, les content edit handler et l'API pour organiser ses contenus dans une logique de WorkFlow (déplacement des noeuds en fonction de leurs statuts dans tel ou tel "parent").
- Utiliser les noeuds cachés et l'API pour afficher ou masquer les contenus en fonction des actions de modérations
Mais tout ceci devrait se simplifier avec l'arrivée des Object States, alors courage...
La boutique est vraiment lourde par rapport aux fonctionnalités proposés
Effectivement, le "Shop" d'eZ Publish n'est pas vraiment destiné à supporter des logiques de boutiques avancées, et son déploiement est un peu fastidieux. Pour cela il vaut mieux investir sur Magento (on inverse alors la problématique avec la logique CMS très pauvre de Magento...).
Cependant, lorsque la boutique est basique, minoritaire dans le site et/ou nécessite de forte connexions entre les données, cela reste une bonne solution pour ne pas avoir à s'embarquer dans le déploiement d'une galaxie d'outils hétérogènes à interconnecter par de coûteux moyens (synchronisations de données, SSO, moteur de recherche externe, etc.). On pourrait d'ailleurs étendre se raisonnement à d'autres briques, comme le Forum, le Blog, le WIKI, etc.
Le mécanisme de forum fourni de base est assez mauvais. Trop simpliste. Aucune modération prévu de base etc...
On retrouve la même logique que pour le Shop, le Blog... à savoir eZ Publish n'a pas vocation à concurrencer les outils Open Source "spécialisés" dans leurs domaines (phpBB, punBB, IPB, etc.), mais plutôt de proposer un CMF qui permet de développer soit même ce genre d'outils, à l'aide d'un ensemble de briques de gestion de contenus très avancés.
Le forum, contrairement à la boutique, exploite uniquement les briques de publications (classes, objets, noeuds), sans fonctionnalités spécifiques. Il est donc relativement simple d'étendre le mécanisme par défaut à son besoin, en enrichissant les classes et les templates, et en profitant des fonctionnalités natives pour gérerses connexions de contenus, son moteur de recherche, ses rubriques privées, son "usine à forum", etc.
Par ailleurs, les systèmes de Forum sont souvent des usines à gaz surchargés de gadget inutiles, et la sobriété d'un mécanisme de type "sujets", "messages" nous rappellent parfois que les outils les plus simples sont les plus efficaces.
- Tags :
- Workflow
- eZ Publish
Que boire avec ce billet ?
Mas de Daumas Gassac - Rouge 2004
| Région : | Languedoc |
| Appellation : | Vin de Pays de l'Hérault |
| Domaine : | Mas de Daumas Gassac |
| Couleur : | |
| Stock : | 5 |
| Notation : | |
| Prix : | 17 € |
| Commentaire(s) : | 0 Commentaire(s) |
Acheté en primeur (ce qui explique le prix), et après avoir dégusté des cuvées 95 et 96 splendides, il est évident que ce 2004 doit attendre, en espérant retrouver l'émotion de ses prestigieuses anciennes cuvées.
Note de dégustation : le millésime 2004, après 5 ans de garde est toujours anodin. Il faut se rendre à l'évidence, ce domaine ne produit plus de grand vins mais plutôt des bouteilles pour les touristes.
fetch et compagnie
Sur la partie fetch je rajouterais qu'avec cette entorse au sacro-saint MVC, il est possible de faire un site eZ Publish (simple) sans écrire une ligne de PHP. En revanche, la tentation d'en faire trop est souvent à l'origine de bien des problèmes de performances (c'est très certainement lié à la "polémique" 
). Comme souvent c'est à double tranchant.
Pour le reste (forum, boutique, autres remarques du commentaire d'origine) comme tu le dis eZ Publish est à la limite de CMS et du Framework (avec un w minuscule :p, CMF comme certains disent), donc si la fonctionnalité est trop basique il est possible de l'améliorer. Il faut quand même se souvenir que la philosophie de l'outil est d'être extrêmement générique/modulable pour justement en faire ce qu'on veut, il ne faut pas s'attendre à avoir des fonctionnalités (au sens utilisateur) très avancées, en revanche toutes les briques sont là pour y parvenir. Par exemple, je pense qu'il est possible de faire un excellent logiciel de forum à base d'eZ Publish, en tout cas tout est là pour le faire mais ça demande un peu d'intégration.
Promesse tenu!
Et bien bravo! Parole tenu!
Bon je ne reviens pas sur ma position, tout a déjà été dit. J'attendais bcp des object states et la le drame... pas de notifications par mail quand il y a un changement d'état... drôle d'oublie pour LA killer fonction qui est senser mettre les Workflows au placard.
Je suis qd même sur le cul qd je lis l'article sur ez.no ou ils écrivent sans vergogne, quand Bill à fini son travail il change l'état et envoi un mail à paul pour signaler qu'il a fini. Elle est ou la notion de collaboration la? comment il faut Bill si il faut mailer un groupe d'utilisateur qui change assez souvent? Enfin bref, encore une vision simpliste du problème de travail collaboratif, mais ca va dans la bonne direction.
Je réagit aussi au commentaire de damien "il est possible de faire un site eZ Publish (simple) sans écrire une ligne de PHP." Et la je me dis quel intéret? Globalement, tous ceux qui font des sites web maitrise plus PHP/Python/Ruby que le language de templating d'Ez.
Je passe une bonne partie de mes journée à chercher dans la doc comment faire tel ou tel chose qui me prendrai 5s en php. Pour une fonctionnalité j'ai même renoncé à le faire dans la template, j'ai écrie mon opérateur maison en 5min.
Je finirai en disant qu'écrire un langage de templating en PHP est une connerie.
* Temps d'interpretation double
* source de plein de bug dans l'implémentation de ton meta-langage
* un autre langage à apprendre, entre HTML, XHTML, XHTML5, CSS2, bientot CSS3, javascript et PHP/Python/Ruby, pas la peine d'en rajouter un de plus, qui n'apporte pas grand chose de plus
<Fin du mode RANT>
Maintenant les bonnes choses:
* La Création/Gestion des classes de contenu est bien ficelé
* La gestion des Arborescences est bien faite (d'ailleur peut-on ajouter une autre arbo à coté de content et media facilement?)
* La gestion des droits est très complète
* L'approche des notifications est très réaliste
Ce qui rendrai EzPublish parfait:
* Une doc à jour sur un site rapide et efficace (ca reglerai bcp de problèmes sur LA polémique d'ailleurs)
* Une meilleur gestion du multi-site
* Des modules shop blog forum plus proche des besoins réels
* Des modules dédié à l'intégration d'outils spécialisés, quand ca sort du champs Ez
* Des outils pour valider et tester modules et templates
ps; je serai p-e à l'Ez Community Day le 8 avril! qui y sera?
Bon et bien je n'ai plus qu'a trouver une bouteille de Mas de Daumas Gassac - Rouge 2004 maintenant ^^
...
"Je réagit aussi au commentaire de damien "il est possible de faire un site eZ Publish (simple) sans écrire une ligne de PHP." Et la je me dis quel intéret? Globalement, tous ceux qui font des sites web maitrise plus PHP/Python/Ruby que le language de templating d'Ez."
Je soulignais la possibilité de pondre un site avec peu de code et du code simple. Quoi qu'on en dise, le langage de template est plus simple à utiliser que l'API PHP d'eZ Publish... Sinon le fait d'écrire un opérateur lorsque ça devient compliqué est la bonne chose à faire.
L'utilisation ou non d'un langage de template est un vaste débat, je te conseille la lecture des commentaire de ce billet [1], ça a quand même quelques intérêts. Enfin, il faut pas déconner, le langage de template est quand même pas compliqué, si il le devient c'est le signe qu'il faut faire un opérateur.
Pour le reste, on attend tes contributions :-p
[1] http://www.glagla.org/weblog/2009...sert-un-moteur-de-template-pour-php/
...[2]
J'aimerai bien avoir le temps de faire quelques contrib... notamment une extension d'intégration shopify ou magento
* Concernant l'API PHP Ez est effectivement perfectible. A comparer à l'API Symfony/Zend pour la bonne route à suivre
* Le langage de template Ez reste simple tant que tu sort pas des clous, et je trouve le cadre ou le templating Ez est réellement efficace est très petit. De plus comme dit plus haut ce n'est pas vraiment de la template ou sens ou on l'entend normalement vue qu'on y ajoute de la logique.
Mais en vraie j'aime bien cet outil hein, ne vous méprennez pas! ^^
Ravie de vous avoir présenté
@Damien : « Par exemple, je pense qu'il est possible de faire un excellent logiciel de forum à base d'eZ Publish, en tout cas tout est là pour le faire mais ça demande un peu d'intégration ».
Effectivement, un Forum ou un Blog fonctionnellement complet, tout en conservant la possibilité de développer d'autres rubriques "sur mesure", sur un socle unique. C'est un peu l'effet démonstratif de ce site (entre le classique Blog et la curieuse cave en ligne partageant les même contenus). Mais je pense pas qu'on est besoin de se convaincre mutuellement
@Sylvain_G : Les objects states n'ont pas vocations à fournir un Workflow, mais plutôt une brique manquante, permettant de construire un vrai workflow sur mesure, en combinant avec les autres briques déjà disponibles, ou ayant évoluées avec la version 4.1 (comme par exemple les ajouts au niveau des content edit handler, permettant de router les fameux mails au besoin).
@Sylvain_G : Concernant l'éternel débat « template » contre « php », je trouve bien des défauts aux langage de template d'eZ, mais pas celui d'exister. Les templating ont bien des vertus, comme par exemple :
La séparation entre le contenu ou la présentation (comme le précise Damien)
La sécurisation du code en imposant un périmètre pour les manipulations les plus courantes
La préservation de l'intégrité du moteur pour les montées de versions (rôle d'une couche intermédiaire)
Le travail en équipe (dev pour moteur, dev pour frontal)
Tu me diras, tout ceci ne serait pas nécessaire si les templates ne contenaient que des inclusions de données, ou des helpers... Mais dans ce cas il faut travailler avec un FrameWork et pas un CMS (retour cas « voir le billet »).
Quelques règles
Hello,
Bon, je suis un peu un puriste dans le domaine, n'en déplaise à certains, mais je trouve que le langage de template est une excellente chose. Je dis ça pour les gens qui n'ont jamais fait du J2EE parce que bon, le templating eZ c'est vraiment de la boulette.
Il y a quand même une origine au moteur de template, c'est pas un mec tout seul qui s'est dit, je vais rajouter une couche pour embêter tout le monde... Ce qu'il faut donc se demander, c'est quel est le réel objectif d'un moteur de template ? A mon sens, j'en vois plusieurs :
- Il y a effectivement une couche d'abstraction qui va nous permettre de séparer le rendu du traitement, le controleur de la vue. En principe, nous ne sommes pas sensés faire des requètes via fetch ou autres dans un template, ça doit juste être un HTML à trou.
- du fait de la séparation, le changement d'une des briques amont, le controleur ou le modèle, ne devrait pas altérer nos templates. Bon, dans le cas d'eZ c'est plus ou moins vrai puisque même eZSystems n'arrive pas à intégrer complètement le ezcTemplate dans eZ.
- enfin, et toujours à mon sens, avec quelques règles simples, on peu disposer d'un langage super clair pour afficher le rendu. L'utilisation des fonctions gui d'eZ permet une souplesse inégalée dans le découpage de nos vues.
Voilà, arrêter de taper sur eZ.
Pour info, certains on déjà essayé de demander à Paul Borgermans si il allait retirer le moteur de template dans la v4. Comique...
Max
@Maxime
@Maxime : je te rejoint sur les points fort d'un langage de templating.
- Séparation du fond et de la forme
- Isolation des couches applicatives
- Gestion des formats de restitutions, y a pas XHTML dans la vie, y a aussi XML, json, RSS
De ce point de vue la Un langage de templating a son intéret. Je pense juste que dans le cadre d'Ez le templating ne remplit pas les vraies missions sus nommé, qu'il y a une certaine complexité pour réaliser certaines choses (notamment qd faut gérer des recherches complexes, manipuler le module shop, gérer le contenu des mails de notifications etc).
Bon maintenant, c'est la, et ca rend qd même un certain nombre de services.
Le vrai défaut
En fait y en a deux:
1. Le code noyau php5 mais pas vraiment, notamment y a plein de classes abstraites / Interfaces mais pas noté comme tel. Je le note car je viens de faire une petite visite dans le code kernel "shop" conçernant l'envoi du mail de confirmation de commande. Pas simple de retrouver l'implémentation utilisé pour l'eZConfirmOrderHandler (nom approximatif)
J'ai commencé à faire une recheche global sur "extends eZConfirmOrderHandler" et la rien aucun resultat... dommage, ca rend le code assez dur à lire. Du coup pour trouver comment envoyer un mail text ou html, pas simple (et en plus j'ai pas trouvé de lien entre l'order et l'eZPaymentObject utilisé pour cette commande)
2. On l'a déjà dit mais je le remet (et j'en parlerai demain) on est obligé d'aller lire le code pour comprendre certain fonctionnements alors qu'une doc ferai tellement mieux.
ps: d'ailleurs EzSystem cherche des rédacteurs techniques!!
enjoy !
Vous allez vous amuser aujourd'hui
soyez sage quand même ! ! !
Ca discute fort !
Belles discussions que voici ! Et merci Gilles pour ce billet.
Je me permettrai un petit avis concernant les templates, vu que c'est une discussion que j'ai avec beaucoup de monde depuis... 2002 ? Environ ça oui
Il faut bien voir comment fonctionnent les templates ici (et comme quasi partout ailleurs): ils sont compilés en PHP, et interprétés par la suite. La "lourdeur" d'intérprétation des templates est donc entièrement reliée à la lourdeur d'exécution du code généré, ni plus, ni moins. Or nous sommes d'accord, le code généré par eztemplate est au mieux médiocre. En étant gentils. Par contre, quand on regarde celui généré par ezcTemplate, c'est le jour et la nuit. Je connais des développeurs qui font du code plus mauvais que ça à la main, sérieusement. Du coup, le coût d'exécution des templates compilés devient négligeable.
Après, aimer les templates ou pas, c'est une autre discussion. Personnellement je n'aime pas faire sans (séparation), mais je comprends qu'on ne soit pas fan. Dire ensuite que ça fait un langage de plus à apprendre, je classe ça dans le troll, navré: entre apprendre l'API eZ publish et apprendre l'API template... la dernière est tout de même largement simplifiée non ? Du pour et du contre, et à mon avis pas de réponse parfaite ou absolue.
un article communautaire?
ezTemplate vs ezcTemplate j'avoue que je sais pas trop de quoi tu parle mais ca a l'air intéressant, IMHO tu tiens un bon article communautaire la! ^^
Sinon les trolls c'est sympa, surtout la "Cuvée des Trolls" http://www.cuveedestrolls.com/
