Faire de l'édition frontale AJAX avec eZ Publish & Mootools (Partie 1)
- Publié le 20 Septembre 2009
- 8 commentaire(s)
- Catégorie : Technologies Web
La rubrique ma cave est certes un bon prétexte à la rédaction d'articles techniques sur eZ Publish, mais il s'agit également de la seule information numérique à jour concernant mes stocks de vins. Le volume des entrées / sorties est relativement important (si si !) et cette mise à jour des stocks est rapidement devenue un calvaire. La recherche d'une bonne solution de feignant m'a permis de tester l'édition frontale sur eZ Publish, et surtout d'expérimenter un mécanisme de mise à jour plus immédiat en AJAX du type : "cliquer / éditer".
J'en profite pour rédiger une série de billets détaillant :
- Le fonctionnement et les limites de l'édition frontale standard
- La programmation orientée objet en JavaScript avec Mootools
- La mise à jour de contenus eZ Publish via AJAX
La classique édition frontale eZ Publish et ses limites
L'édition frontale est le mécanisme le plus exploité pour promouvoir les CMS (eZ Publish, Drupal ou autres), ce qui est relativement paradoxal, puisqu'au final il s'agit du mécanisme le moins exploité par les Webmasters sur les sites en productions. Ce constat s'explique assez bien, pour plusieurs raisons que je détaille par la suite.
Pourquoi si peu de sites exploitent l'édition frontale ?
La logique ergonomique de l'édition frontale est des plus simple : je navigue sur mon site, et une barre d'édition me permet :
- d'éditer l'objet que je suis en train de visionner (sa vue 'full')
- d'ajouter un objet de contenu positionné "en dessous" de l'objet que je suis en train de visionner
- quelques autres actions classiques comme 'déplacer', 'ajouter des emplacements', 'supprimer', etc.
Donc la capacité d'éditer (ou non) un contenu dépend de la capacité d'atteindre une page dont le contenu principal est le contenu à éditer (vue full), ce qui se complique fortement dès qu'il s'agit d'une liste de commentaires (généralement empilés, sans affichage individuel), d'un utilisateur, d'un contenu associé à partir de la médiathèque (image), d'un contenu non représenté dans l'arborescence de l'internaute (divers dossiers de rangement), d'un contenu masqué ou supprimé, etc..
Les Webmasters vont donc devoir naviguer entre l'édition frontale et le Back Office, ce qui finalement se résume assez vite à l'utilisation exclusive du Back Office.
Il faut aussi ajouter que les front-end des sites sont très variés dans leur logique de navigation, et parfois graphiquement inadaptés à l'inclusion de formulaires d'édition. Pour pouvoir profiter d'une édition frontale efficace, il faut en quelque sorte organiser le contenu en conséquence, ce qui cependant fonctionne positivement sur certains types de publications, comme les Blogs ou les contenus arborescences (catalogues, référentiels).
Pourquoi vendre un CMS à l'aide de l'édition frontale ?
Les acheteurs des solutions Web sont rarement les utilisateurs finaux, et il faut donc les séduire avec des mécanismes percutants et rassurants tels que l'édition frontale, l'upload massif (voir ezmultiupload), ou l'importation directe à partir de Word (voir ezwordtoolbar) ou Open Office (extension native ezodf). Généralement un CMS succède à du DreamWeaver (fabrication HTML frontale) ou du PHP maison (bricolé, insécure, mais libre d'action), il faut donc insister sur des mécanismes qui ne suppriment pas définitivement des conforts de fabrication durement acquis au fil du temps...
Installation d'une édition frontale sur eZ Publish
De nombreux articles détaillent déjà l'installation de l'édition frontale (que l'on trouve par défaut lors de l'installation des packages ezwebin ou ezflow), comme par exemple :
Il est à noter qu'une nouvelle extension ezwebsitetoolbar (code extrait de ezwebin) permet d'intégrer une barre d'édition frontale sans transporter l'ensemble de l'extension ezwebin.
L'interface de mise à jour des stocks ?
En posant le problème, l'idéal ergonomique pour cette mise à jour fréquente est finalement de pouvoir cliquer et éditer le stock directement dans la page quel que soit la page affichée (les listes de cuvées résumées, les tableaux de stocks, les fiches détaillées, etc.). Ce mécanisme est particulièrement efficace pour des mises à jour multiples sur des affichages en tableaux (vue d'ensemble).
Voici un exemple en vidéo, qui montre en image :
- Un exemple de boite de connexion frontale
- Un exemple de mise à jour du stock par l'édition frontale standard
- Un exemple de mise à jour du stock par un développement spécifique, permettant le "cliquer / éditer" en AJAX avec Mootools
- Ce même mécanisme décliné pour mettre à jour les noms des cuvées (je modifie souvent l'année dans le nom des cuvées)
Les prochains billets détailleront pas à pas le développement d'une telle extension.
Que boire avec ce billet ?
Domaine Richard Leroy - Les Noëls de Montbenault - Blanc Sec 2006
| Région : | Loire |
| Appellation : | Anjou |
| Domaine : | Domaine Richard Leroy |
| Couleur : | |
| Stock : | 1 |
| Notation : | |
| Prix : | 16 € |
| Commentaire(s) : | 2 Commentaire(s) |
stats ?
En parlant de stock de vin, ta méthode c FIFO ou LIFO ?
ya des stats annuelles avec des tendances ? :
- mois le plus / moins consommé
- domaine le plus / moins consommé etc...
Oui c'est mon petit côté analyse de fichiers excel....
Versioning?
Cool, did a similar thing a couple of years back for a customer and some of the code ended up in ezcore but since the question regarding versioning or not came up it was never completed in ezcore.
So, do you version or not when you ajax edit? I guess not, wouldn't make much sense in this case.
Mooo ou YUI mais tjrs AJAX
Intéressant comme toujours. J'ai hate de lire la suite.
Par contre j'ai l'impression que eZSystem à finalement fait le choix YUI avec l'intégration de eZJsCore dans la future ez4.2. Va falloir t'y mettre que tu le veuille ou non ^_^
Response :
@fonfec : Bonne idée d'extension, ca va pouvoir occuper mes soirées, par exemple en utilisant l'API de Google Analytics
@André : I'm not using versioning, but it could be a next feature
@Sylvain : Il s'agit d'une fonctionnalité Front-end, alors autant utiliser les librairies déjà en place. D'ailleurs la future eZJSCore utilise YUI 3.0 qui se rapproche sensiblement des possibilités de Mootools. Je vais attendre un peu avant de l'exploiter en Front-end 
Alternative aux flash
Mis à part qu'il n'y a même pas une image en alternative au Flash (ni une audio description d'ailleurs), l'idée est intéressante mais durant les folles années d'Ajax, je me suis pris souvent la remarque suivante : " on refait du Frontpage, je rapatrie ma page, je la modifie et je la remet sur le serveur". Et quelque part, ils n'ont pas tort.
un autre désavantage de cette approche est aussi qu'il y a une corrélation importante entre la modification du contenu et les répercutions sur le site visible pour l'utilisateur final. Cette association fait généralement peur. Un webmaster se sentira plus en sécurité derrière un back-office. C'est d'ailleurs une des raisons qui ont permis d'asseoir la domination des CMS, la capacité à fournir une interface qui les rassure dans l'édition de contenu Web.
P.S. : Et pourquoi pas utiliser JQuery ? (c'est bon je sors)
J'ai oublier
@fonfec je pense que c'est la méthode FISO
yui / ezjscore
@Sylvain_G / gandbox: ezjscore also support jQuery and has for a while in addition to YUI 3.0.
ezstarating also supports both, and uses the one you prefer by setting in ezjscore.ini. It's fully possible to add support for Moo Tools as well, but preferably not as there is more to maintain the more libs we add.. :/
Edition Front End Ajax
Pour revenir au sujet l'édition Front Office Ajax je pense que c'est une fonctionnalité très efficace dans certains cas, mais certainement pas à mettre partout et entre toutes les mains.
C'est aussi comme tu l'as dit une "Killer Feature" dans une démo, pourquoi? j'y vois plusieurs raisons
1. C'est Kewl, et oui, web 2.0, application réactive, tous ça...
2. C'est simple, pour éditer ton stock en back office je vois d'ici la galère, aller dans le back office, retrouver ton contenu dans l'arbo, l'éditer, et la republier, vérifier
3. Ca donne plus d'interactivité : tu veux changer ca? click dessus!
4. La confiance, l'utilisateur en cliquant sur la zone est sure d'éditer cet élément précis. En basculant dans un back office on va retrouver de nombreux contenu et de nombreux champs, pas toujours facile de s'y retrouver pour un rédacteur éditorial.
Comme tu peux le remarquer je distingue l'édition Front Office (eZWebToolbar sous eZ, ou en standard sous Drupal par exemple) et l'édition Front Office Ajax qui à mon avis doit se limiter à certaines zones du site (des blocs éditoriaux, des données tabulaires, ordonnancer manuellement certains listes).
En un mot il y a de réels intérêt à l'édition front end AJAX, ce n'est pas seulement un truc de démo qui pète!
Quand à la lib à utiliser, je te rejoint complêtement, autant utiliser un framework js déjà en place.
ps: en attendant elle claque ta vidéo ^^
