- Publié le 26 Novembre 2009 à 23:23
The big new feature of the roadmap of eZ Publish 4.3 is a new admin interface. The work on it has started with a requirements document and a prototype of a page (download it locally if you want to see it in your browser). jQuery is used in the prototype, I don't know if it's a definitive choice, but as I have already said on that topic, a choice of a framework is better than no real choice (even if jQuery is not my preferred JavaScript framework). I think that most of the big needs are already covered in the document but there are some small details that miss in the current admin interface that I would like to see in the future one :
- Labels of each field should be linked to their related input with the for attribute. That's a very small addition but I find it more than useful in web applications.
- The focused input should be highlighted with a different colour. This is another very small improvement which can greatly improve users experience.
- Buttons in the admin interface should be of a different colour depending on the action they trigger. For instance cancel buttons can be orange, publish buttons blue, remove buttons red, ... The main key here is to be consistent over all the interface.
The edit interface of each datatype should also be considered individually to provide the best interface. For instance, the edit template of a datetime attribute should provide a JavaScript calendar (like with the ezwebin package), the template of a time attribute a button to fill inputs field with the current time, the keyword datatype an autocomplete input (like with the ezkeywords_autocomplete extension), ... Beside an advanced edit interface for each attribute, the data entered in the edit form should also be checked with JavaScript (required or not, valid syntax, ...). In case of errors, fields that do not validate should be highlighted with a message until a new valid value is entered. Obviously, if JavaScript is disabled, a server side check should do the same thing. On this topic, there's also a very old feature request in the issue tracker about the ability to add an help text in the class definition that would be displayed under the edit interface of the attribute.
Finally, a great improvement would be to apply general rules on performances frontend. I think of packing and minifying CSS et JavaScript files (with ezjscore !), using CSS Sprites for design images and use optimized PNG files instead of GIF files. This would improve the user experience by speeding up response time and making the admin interface usable with a slow Internet line
- Publié le 01 Octobre 2009 à 22:11
Comme je l'écrivais il y a quelques jours, le backoffice de Magento est plutôt sympa mais un peu mou. En plus les options pour le développeur sont bien cachés au fin fond du menu System. Si je compte bien, à partir du tableau de bord il faut pas moins de 7 clics et 4 rafraîchissements de page pour activer ou désactiver l'option Template path hints (affichage des templates utilisés) et/ou l'affichage du nom des blocks pour un site... Bref c'est extrêmement pénible quand il s'agit juste de voir où se trouve une coquille dans un template ou de connaître le nom du block à surcharger.
J'ai donc un écrit un petit script (version avec coloration syntaxique) qui permet d'activer ou de désactiver ces options pour un site Magento en ligne de commande. Il permet également d'activer facilement ces options pour le backoffice sans manipuler directement la base de données (ce qui n'est certes pas très compliqué une fois qu'on connaît le nom de la bonne table).
Exemples d'utilisation :
cd /path/to/magento
php /path/to/script/setdebug.php -s base # active template path hints pour le site dont le code est base
php /path/to/script/setdebug.php -b -s base # active template path hints et l'affichage des blocks
php /path/to/script/setdebug.php -d -s base # désactive template path hints et l'affichage des blocks
- Publié le 28 Septembre 2009 à 22:47
Je travaille depuis très exactement 13 jours sur un projet Magento histoire de changer un peu d'eZ Publish. Bon, en réalité j'ai fait 2 jours de formation et 11 de développement plus une petite expérience d'optimisations côté système. C'est certes trop court pour en saisir toutes les subtilités techniques mais c'est largement suffisant pour y voir de très bonnes choses et de beaucoup moins bonnes.
Parmi les excellents points :
- la flexibilité et l'extensibilité : grâce à l'alliance du modèle EAV et à la possibilité de surcharger proprement presque tout le core.
- le système d'installation et mise à jour des modules qui résout pas mal de problèmes liés au développement collaboratif sur plusieurs plateformes différentes avec de multiples informations stockées en base de données
- l'ergonomie générale du backoffice mais ...
Dans les moins bons points :
- le backoffice est lent, vraiment très lent; il n'y a pas (encore) d'éditeur WYSIWYG vraiment intégré, l'accessibilité est loin d'être parfaite (j'aime naviguer dans les formulaires au clavier...), et si une requête AJAX n'aboutit pas pour cause d'expiration de la session, rien ne se passe, pas de message d'erreur, juste rien...
- Magento utilise directement PHP comme langage de template, je ne suis pas fan (je ne vais pas relancer le débat), en revanche quand je vois des templates comme price.phtml, j'ai mal à la tête rien qu'en pensant devoir le modifier un jour...
- la version Entreprise de Magento embarque à la fois Prototype/Scriptacoulous et jQuery, je semble être le seul que ça choque pourtant quand on connaît l'impact de quelques centaines de millisecondes de latence supplémentaire, l'optimisation du temps chargement devrait être encore plus prioritaire sur un outil de boutique en ligne.
- Publié le 26 Août 2009 à 18:13
I answered this question today on IRC and a colleague asked me the same thing about two weeks ago... it's time to write down the solution :-)
Basically, you just need to tell what design keys you want to use and their value to the template engine of eZ Publish. The design keys are the parameters you will be able to use in an override condition. Let's take an example with a simplistic PHP view (it lacks a lots of checkings) :
<?php
require_once 'kernel/common/template.php';
$NodeID = intval( $Params['NodeID'] );
$node = eZContentObjectTreeNode::fetch( $NodeID );
$tpl = templateInit();
$tpl->setVariable( 'node', $node );
// setting up the context to use override conditions
$res = eZTemplateDesignResource::instance();
$designKeys = array( array( 'class_identifier', $node->attribute( 'class_identifier' ) ),
array( 'parent_node_id', $node->attribute( 'parent_node_id' ) ) );
$res->setKeys( $designKeys );
$tpl->fetch( 'design:mymodule/myview.tpl' );
?>In this code, I define two design keys : class_identifier and parent_node_id, so I can write override rules that match on the class identifier or on the parent node id of the node or on both, for example :
[myview_folder]
Source=mymodule/myview.tpl
MatchFile=myview/folder.tpl
Subdir=templates
Match[class_identifier]=folder
With this override condition, eZ Publish will use the template located in override/templates/myview/folder.tpl in the design when the node is a folder, otherwise it will use the default one (templates/mymodue/myview.tpl).
