Date de publication: le samedi 12 avril 2008 à 18h16
Dernière modification: par Pascal BOYER le dimanche 26 septembre 2010 à 22h28
« Article précédent: Good template practices / Les bonnes pratiques avec les templates
» Article suivant: Miscellaneous performance settings / Différents paramètres de performance
An optimized pagelayout template should generate only two or three SQL queries with viewcache enabled. When building a site, you normally have several dynamic elements in your main template pagelayout.tpl. This template will then use most of the total processing time for your site, which is undesirable. To limit this processing time, you can use the cache-block template function.
Un template pagelayout.tpl optimisé ne devrait générer guère plus de deux à trois requêtes SQL lorsque le cache des vues est activé. Pendant la phase de création d'un site vous disposez normalement de plusieurs éléments dynamiques dans votre template principal pagelayout.tpl. Ce dernier utilisera la presque totalité du temps de traitement de votre site. Or c'est justement cela qu'il faut éviter. Pour limiter ce temps de traitement, vous devez utiliser la fonction cache-block des templates.
How it works / Fonctionnement
The cache-block function stores the result of dynamic template code in a plain HTML/text file to be loaded the next time the same code is requested.
La fonction cache-block stocke le résultat du code dynamique d'un template dans un fichier HTML/texte pour que ce résultat soit chargé (affiché) lorsqu'une prochaine requête demandera le même code.
For example, a navigation menu usually consists of a list of folders and / or objects. This menu is often the same for most or all pages. You can use a cache-block to store the result of the dynamic code.
Un menu de navigation, par exemple, est souvent composé d'une liste de dossiers et/ou d'objets. Ce menu reste le plus souvent inchangé pour la plupart des pages. Vous pouvez donc utiliser la fonction cache-block pour stocker le résultat du code dynamique.
Consider the following main template file (pagelayout.tpl) example:
Considérons l'exemple de template principal pagelayout.tpl suivant:
<html> <head> <link rel="stylesheet" type="text/css" href={"stylesheets/core.css"|ezdesign} /> <link rel="stylesheet" type="text/css" href={"stylesheets/debug.css"|ezdesign} /> {include uri="design:page_head.tpl" enable_glossary=false() enable_help=false()} </head> <body> {include uri="design:page_toppath.tpl"} {cache-block} {include uri="design:left_menu.tpl"} {/cache-block} {$module_result.content} {include uri="design:page_copyright.tpl"} </body> </html>
In this example, we have added a cache-block around the left menu navigation code. This means that the first time the page is loaded, this code is executed and the result is stored in a text file. During successive pageloads, this text file is loaded and no left menu code is executed. This happens until the cache-block expires (which is by default two hours).
Dans cet exemple, nous avons ajouté un cache-block autour du code du menu gauche de navigation ce qui signifie que lors du premier chargement de la page ce code est exécuté et que le résultat obtenu est stocké dans un fichier texte. Pour les prochains chargement de cette page, c'est ce fichier texte qui sera chargé et le code du menu gauche ne sera donc pas exécuté. Ce fonctionnement opérera jusqu'à expiration du cache-block (au bout de deux heures par défaut).
Parameters / Les paramètres de la fonction cache-block
The cache-block function takes four parameters: keys, expiry, ignore_content_expiry and subtree_expiry.
La fonction cache-block accepte 4 paramètres: keys, expiry, ignore_content_expiry et subtree_expiry.
Keys
The keys parameter is used to define the uniqueness of the cache-block. By default, eZ Publish uses the template name and position of the block as keys. This means that if the cache-block is common for all occurrences of a given template (normally pagelayout.tpl), you do not need to specify any keys. An example of this would be a menu that does not change even for different users or different areas of the site.
Le paramètre keys détermine l'unicité du cache-block. Par défaut, eZ Publish utilise comme valeurs de ce paramètre le nom du template et la position du bloc. En clair, si le cache-block est commun à toutes les occurrences d'un template donné (normalement pagelayout.tpl), alors il n'est pas nécessaire de spécifier une quelconque clef (keys). Un exemple serait un menu restant inchangé quelque soit l'utilisateur ou la section/partie du site.
If you need to specify a key you can use either a single variable or an array, as shown in the following example with cache-blocks that are unique for each URL:
Pour spécifier une clef vous pouvez, comme le montre ci-dessous l'exemple de cache-blocks unique pour chaque URI, soit utiliser une simple variable soit un tableau:
{cache-block keys=$uri_string} ... tpl code {/cache-block}
Here is an example with cache-blocks that are unique for each URL and user:
Voici un exemple de cache-blocks unique pour chaque URI et chaque utilisateur:
{cache-block keys=array($uri_string,$current_user.contentobject_id)} ... tpl code {/cache-block}
Expiry
If you do not specify the expiry parameter, the cache-block will automatically expire in two hours or if new content is published.
Si vous ne spécifiez pas le paramètre expiry alors le cache-block expirera automatiquement soit au bout de deux heures soit lors de la publication d'un nouveau contenu.
If this expiry does not fit your needs you can specify the expiry time manually in seconds:
Si ce fonctionnement par défaut ne vous convient pas, vous pouvez définir manuellement un délai d'expiration exprimé en secondes:
{cache-block expiry=120} ... tpl code {/cache-block}
Ignore_content_expiry
Sometimes you do not want your cache-blocks to expire when content is published. For example, a footer containing copyright information is not affected by new content and thus does not need to expire. With the ignore_content_expiry parameter you can disable the expiration when content is published:
Vous souhaiterez parfois que les cache-blocks n'expirent pas lors de la publication d'un contenu. Par exemple, un pied de page contenant le copyright n'est pas affecté par la publication d'un nouveau contenu. Il n'est donc pas nécessaire de lui affecter un délai d'expiration. C'est le rôle du paramètre ignore_content_expiry de désactiver le processus d'expiration lors de la publication d'un nouveau contenu:
{cache-block ignore_content_expiry} Cached content, even if an object is published. {/cache-block}
In between the default policy of always expiring the cache-blocks when content is published and the functionality of >ignore_content_expiry is the subtree_expiry parameter. With this parameter, you can control the expiration of a cache-block when content in a specific subtree (like /products) is published; there might be a block inside the pagelayout template containing a list of the five latest products. In the following example, the cache-block will expire when there is something published in the /products/bargain subtree or after 30 minutes:
Entre le comportement par défaut consistant à toujours expirer les cache-blocks lors de la publication d'un contenu et le fonctionnement qu'impose le paramètre ignore_content_expiry on trouve le fonctionnement du paramètre subtree_expiry. Vous pouvez, avec ce dernier, lier l'expiration d'un cache-block à la publication d'un contenu situé dans un (sous-)répertoire spécifique (comme par exemple /products). Il pourrait y avoir, par exemple, dans le template pagelayout.tpl un block contenant la liste des 5 derniers produits. Dans l'exemple ci-dessous, le cache-block expirera lorsque quoique ce soit sera publié dans le sous-répertoire /products/bargain ou bien au bout de 30 minutes:
{cache-block expiry=1800 subtree_expiry=/producs/bargain} ... tpl code {/cache-block}
Usage tips / Conseils d'utilisation
Since there is some processing involved in using the cache-block itself, you should use as few cache-blocks as possible and make them unique using keys.
Puisque l'usage des cache-blocks engendre des implications au niveau du traitement, vous devez utilisez le moins possible de cache-blocks et les rendre uniques grâce à l'emploi du paramètre keys.
It is often very efficient to have two large cache-blocks that will cache all header / title / path information and footer information. This can be used in combination with a nested menu cache-block as in the example below:
Il est souvent très efficient de recourir à de grands cache-blocks cachant toutes les informations des en-têtes, des titres, du chemin et du pied de page. Cela peut être mis en oeuvre conjointement à un cache-blocks de menu imbriqué comme le montre l'exemple ci-après:
{cache-block keys=$uri_string} <html> <head> <link rel="stylesheet" type="text/css" href={"stylesheets/core.css"|ezdesign} /> <link rel="stylesheet" type="text/css" href={"stylesheets/debug.css"|ezdesign} /> {include uri="design:page_head.tpl" enable_glossary=false() enable_help=false()} </head> <body> {include uri="design:page_toppath.tpl"} {cache-block} {include uri="design:left_menu.tpl"} {/cache-block} {/cache-block} {$module_result.content} {cache-block} {include uri="design:page_copyright.tpl"} </body> </html> {/cache-block}
Note that when using nested cache-blocks, the outermost block will not know if a sub cache-block has or should have expired. As a result, the outermost block should have a shorter expiry than the sub-block.
Retenez que lorsque vous utilisez des cache-blocks imbriqués, les blocs externes (ceux qui englobent les autres ou ceux de plus haut niveau) ne peuvent pas savoir si un sous- cache-block a expiré ou devrait expirer. Par conséquent, les blocks externes doivent avoir un délai d'expiration inférieur aux délais affectés aux sous- cache-blocks.
Commentaires