- Publié le 23 février 2011 à 09:37
The starting point of this post is an interesting asking of Marty_Nim (aka Nicolas Martinez) on Twitter about the ability to split static components across domains with eZ Publish to improve frontend performances.
Why split components across domains ?
Split components across domains is one of the advices of the Yahoo! Exceptionnal Performances team. This advice is a consequence of the behaviour of browsers that are able to download a limited number of compoments on a given domain at the same time. Following the RFC 2616, old browsers like Internet Explorer 6 or 7 are only able to download 2 components on a domain in parallel while modern browsers (Internet Explorer >=8, Firefox >=3.x, Chrome, ...) are able to download 6 or 8 ressources in parallel. Therefore, this rule is especially useful for those old browsers or if your pages use a lot of different components. It's also not recommended to use too much different domains because of the DNS resolution latency.
In eZ Publish
In eZ Publish, it is very easy to implement this advice for JavaScript files and CSS stylesheets provided the ezjscore operators (ezcss* and ezscript*) are used to include those files. In fact, the ezjscore extension allows to specify a custom hosts depending the extension of the included files. For instance, it's possible to write the following settings in an override of ezjscore.ini file :
[Packer]
CustomHosts[.js]=http://media1.pwet.fr
CustomHosts[.css]=http://media2.pwet.fr
With those settings, eZ Publish will include the JavaScript file(s) from http://media1.pwet.fr, while CSS stylesheets will be included from http://media2.pwet.fr. The later case has an interesting side effect, because the background images used in the CSS files will also be fetched from the custom host.
And what about others components that are directly embed in templates ? Currently, there's no out of the box solution, but as explained by Gaetano on Twitter, since eZ Publish 4.4, it's possible to override template operators so it's possible to write something similar for images, flash, ... embed with ezimage, ezdesign or ezroot template operators even if this should probably be a native feature.
- Publié le 16 octobre 2010 à 23:58
Dans vim il est possible de sauvegarder la session courante avec la commande :mksession (ou avec l’abréviation :mks) suivi d'un nom de fichier, par exemple dans une instance de vim avec plusieurs fichiers ouverts, des buffers ou des onglets... on peut taper :
:mksession ~/test.vim
Cette commande va créer un fichier de session vim (test.vim dans ce cas) qui contient toutes les commandes nécessaires pour restaurer vim dans l'état où il se trouvait au moment où la commande est lancée. Pour restaurer la session, on peut utiliser la commande :so suivie du nom du fichier de session ou alors il suffit de lancer vim avec la paramètre -S :
vim -S ~/test.vim
Ce mécanisme est très pratique lorsque par exemple on doit redémarrer suite à une mise à jour du système mais en l'état il reste manuel. Il m'arrive en effet de temps à autre de fermer par accident le terminal qui contient vim et ainsi de perdre tout l'organisation de l'éditeur. Pour remédier à cela, il est possible de coupler cette fonctionnalité avec le système d'évènement de vim pour sauvegarder automatiquement la session à certains moments.
autocmd VimLeavePre * :mksession! ~/stopped.vim
Avec cette ligne dans la configuration de vim (.vimrc), l'état de la session sera enregistré automatiquement dans le fichier stopped.vim et il est donc aisé de récupérer son environnement suite à une fausse manipulation.
- Publié le 22 septembre 2009 à 00:31
xzoom fait partie de ces petits outils peu connus mais qui peuvent rendre de grands services. xzoom permet de d'agrandir une zone de l'écran quasiment en temps réel, en d'autres termes, à partir du moment où une zone a été choisie (en glissant sur la zone à partie de sa fenêtre), la fenêtre de xzoom se met à jour en même temps que la zone concernée (à l'inverse de xmag par exemple). Cet outil est une aide précieuse pour le montage / l'intégration HTML/CSS lorsqu'il faut caler des blocs avec plus ou moins de contrastes au pixel près.
L'exemple typique d'utilisation est de mettre la fenêtre toujours au dessus des autres dans un coin de l'écran après avoir choisi la zone sur laquelle zoomer. Il est ensuite beaucoup moins fatiguant de vérifier l'alignement correct de zones précises d'une page par un simple rafraîchissement.
Mes yeux remercient l'auteur de xzoom mais continuent de maudir Internet Explorer :-)
- Publié le 26 août 2009 à 20: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).
- Publié le 19 août 2009 à 23:03
J'ai découvert il n'y a pas très longtemps la fonction eZContentFunctions::createAndPublishObject() de l'API eZ Publish. Cette fonction bien cachée (et enfin documentée depuis la résolution de ce bug) permet de créer facilement des objets de contenus. Quand je pense que tout le travail est mâché par cette fonction, ça en fait des lignes de codes inutiles... Par exemple, pour créer un objet de la classe de contenu File, ces quelques lignes suffisent :
<?php
$params = array();
$params['parent_node_id'] = 52; // node id of /Media/Files
$params['class_identifier'] = 'file';
$params['creator_id'] = 14; // admin
$params['storage_dir'] = '/tmp/data/'; // don't forget the ended /
$params['section_id'] = 3; // section media
$attributesData = array();
$attributesData['name'] = 'My file';
$attributesData['file'] = 'my_file.txt';
$params['attributes'] = $attributesData;
$contentObject = eZContentFunctions::createAndPublishObject( $params );
?>
Chaque élément du tableau $attributesData contient les valeurs des attributs du futur objet de contenu sous le format attendu par la méthode fromString() de chaque datatype. Et voila, ce n'est pas plus compliqué que ça ! Dommage qu'il n'existe pas encore l'équivalent pour mettre à jour les objets de contenu existants.
