Ma Wish list pour eZ Publish

• Publié le 09 Juin 2009
• 13 commentaire(s)
• Catégorie : Technologies Web

“

- Tu veux quoi pour Noël ?
- Ha je sais pas, fais moi une surprise !
- Ca te dirait un voyage en norvège ? Les fjords, et tout ça...
- ... NON, on ira pas demander à eZ de refaire son Back Office

”

eZ Publish est en pleine mutation, avec de nombreuses pistes d'évolutions énoncées durant les divers roadmaps, developper days et autres discussions de bloggeurs. J'en profite pour donner ma « liste de voeux » des orientations et des améliorations que je souhaiterais « modestement » voir implémenter sur ce bel outil, en incluant d'ailleurs celles qui sont déjà clairement prévues pour les versions à venir (c'est une façon d'approuver).

Evolutions sur le système d'installation

• Une installation nue pour les experts, sans extensions, ni classes prédéfinies, qui permette ensuite de reconstruire son projet au besoin en ajoutant ses classes et ses extensions à partir d'une base propre
• Un assistant de création de « setup » pour les débutants, ou le choix des langues et des jeux d'extensions (orienté Web 2.0, ou shop, ou encore Extranet) s'effectue sur une interface (avant ou pendant l'installation).

Evolutions sur le projets.ez.no

• Sur http://projects.ez.no/, un explorateur de code (type Trac)
• Sur http://projects.ez.no/, une sélection d'extensions conseillées pour les débutants, par exemple en croisant le nombre de téléchargement, ou en croisant les "toplist" des membres, etc.

Evolutions sur le Back Office

• Redéveloppement des templates, en respectant les bonnes pratiques d'écriture du code (supprimer les mécanismes obsolètes comme les sections par exemple). Le Back Office pourrait ainsi servir de modèle exploitable pour les débutants. Je suppose que cette réécriture aura lieu lors du changement du système de templating (Librairie de Template eZ Components)
• Refactorisation ergonomique entre eZ OE et certains Datatypes. Le Online Editor permet par exemple de parcourir facilement le contenu par diverses méthodes (browse, recherche, signets) lors de l'ajout d'un média ou lors d'une association d'objet (ou eznode), ce qui n'est pas le cas pour les datatypes équivalents (images, object relation, object relations)
• Supprimer ezshop du Back Office par défaut. Les boutiques sont devenues marginales, et rarement exploitées en l'état avec eZ Publish. Autant ne pas favoriser l'exploitation de cet onglet obsolète (et non sécure), qui peut rapidement donner une image négative de l'outil
• Supprimer les interfaces influant sur l'écriture de settings via des formulaires (comme l'activation d'une extension par exemple, ou l'activation des debug). eZ Publish contraint tôt ou tard les développeurs à se confronter à l'exploitation des settings en fichiers, avec une réflexion sur l'organisation des settings et leur surcharge. La double possibilité d'écriture en fichier / interface est dangereuse pour 2 raisons :
  • Elle peut provoquer des situations non maîtrisées (un Webmaster s'amusant avec certaines interfaces)
  • Elle peut freiner l'apprentissage de l'outil, en laissant croire que l'on pourra tout faire à partir des interfaces, ce qui ne sera jamais le cas
• Supprimer les interfaces de manipulation du cache, qui comme les settings génèrent des situations tragiques, alors autant ne pas laisser la possibilité aux Webmaster / développeurs non informés de faire de graves erreurs. Par ailleurs, la suppression de ces interfaces serait une bonne façon de contraindre les développeurs à se préoccuper des mécanismes de cache automatiques (smatviewcache) ou avancées (API), et de laisser enfin les Webmasters s'occuper simplement de la saisie des contenus.
• Plus généralement revoir certaines logiques de navigation dans le Back Office (la médiathèque, le browse par exemple) et revoir le graphisme (pour le rendre plus limpide)

Evolutions plus techniques (pour les experts)

• Etendre le persistent_variable, à plusieurs variables, ou sur un mécanisme non concurrent du principe d'override actuel (actuellement il faut choisir entre l'exploitation pour override ou pour propager des valeurs dans le pagelayout.tpl)
• Revoir le principe des cache_block, pour les rendre plus finement configurable dans leur logique d'expiration
• Etendre le smartviewcache sur d'autres directives, comme par exemple les arbres descendants non relatifs (vider le cache d'un arbre de contenu non lié au noeud courant)
• Pouvoir stocker du contenu dans une base de données ou un container tierce (amélioration déjà sur le roadmap)
• Pouvoir syndiquer facilement des contenus (REST ou SOAP) & synchroniser des contenus entre plusieurs installations eZ Publish (déjà évoqué dans les roadmaps).
• Intégrer une couche basse de Workflow exhaustive (hook à tous les niveaux d'actions), par exemple à partir de la librairie de Workflow d'eZ Components
• Abandonner les librairies PHP hors d'age de l'API (toujours en services pour des raisons d'historique et de compatibilités), et favoriser les librairies plus avancées et mieux écrites, comme les excellents eZ Components (par exemple pour syndiquer du contenu, manipuler les fichiers de settings, etc.). C'est visiblement la démarche actuelle, qui est certes attendue mais délicate, comme par exemple le remplacement inévitable du système de templating qui va fortement compliquer les montées de versions et nécessiter la réécriture complète du Back Office (une bonne occasion à ne pas rater)
• Refaire une documentation de type "référentiel" complète et à jour (un recrutement semble en cours à cet effet), aussi bien pour eZ Publish que pour son API
• Repenser la logique de documentation autour d'un Wiki. L'initiative ezpedia est certes intéressante, mais totalement inaboutie pour plusieurs raisons :
  • Mediawiki serait mieux adapté fonctionnellement (et tant pis pour l'effet démo du style : eZ Publish peut faire un Wiki, l'efficacité prime)
  • ezpedia manque d'animation et d'outils de promotions pour inciter les Blogeurs à contribuer

• Tags :
• eZ Publish