Variable cache layer... Var-block - wouldn't that be something?

Tuesday, 22 April 2008, 19:49
Categories: Lab
Tags: variable cache, var cache, cache control, cache layer, viewcache, cache-block, var-block

It took me fairly long time to figure out what particular tool available from PHP in my custom software and website implementations was missing from eZ Publish... but I finally got it. It's the ability to dynamically, flexibly cache variables, understood as operation or logic results, stored in a reusable form. Naturally, there is no significant need of caching simple variables defined directly within the pagelayout, just like these:

{def $my_var=345}
{def $my_other_var=hash( 'a', '4023' )}

However, it gets worse not being able to cheaply store an array of ten values, whose fetching/generating cost was over fifty or one hundred SQL queries, several files accessed in the file system, etc.


The problem seems quite straightforward - out of many caching techniques and layers in eZ Publish, only two are universally useful: the viewcache and the cache-blocks. Unfortunately, both of them store presentation layer results rather than data, and both are quite independent. As a result:

  1. Whenever you crave for variables that will be used by several cache-blocks in the pagelayout, they must be placed outside of cache-blocks themselves. Don't get fooled by the top cache-block apparently holding the variables used further on - it's a coincidence. This may only work if all expiry times are equal for all the blocks and no subtree expiry is ever used (or you've used bugged eZ 4.0.0 for half-a-year, where subtree expiry is simply broken and it's easy to take it as the default behavior), provided that the blocks never got desynchronized. The point is: variables must be kept outside cache-blocks and they will not be cached.
  2. The module result gets generated before the pagelayout, so there's little reusability between their vars.
So what's missing?

My idea is a cache layer halfway between logic/data and the presentation layer. It could be a variable-dedicated cache-block equivalent (maybe a var-block?).

Example: Imagine a website that for each of its node views should be able to access both current node data (data map) as well as root node data in order to make some decisions, calculations, etc. Further, the data could be required by at least three of its cache blocks (with different expiry times, expiry rules and "uncomfortable" locations within the pagelayout). Today that sort of combination requires a substantial...

The var-block as I imagine it would have expiry settings similar to cache-blocks: subtree expiry, expiry ignore, expiry time and a flexible key management. In order to prevent frequent file system access, var-block could serialize variable collections rather than just singles. An additional "collection name" parameter could help organize the blocks within the pagelayout.

Please let me know what you think.

Here's the prototype:


  • g g
    Saturday, 26 April 2008, 00:46


    I am not yet sure it really does work out, but an alternative way can be using the PERSISTENT_VARIABLE mechanism which is available in eZ Publish.

    As far as I got it:
    - it is calculated inside the node, and stored as extra var in the cached version of the tpl
    - it is then always available in the pagelayout tpl (and from there can be pushed down to included templates)

    how we used it:
    - every node tpl includes the same "calculate the extra stuff tpl", where those extra queries relating to both current node and site data are done, and the results stored in the persistent var
    - the pagelayout tpl uses the persistent var data inside cache blocks, which expire not later than the content does
    - in case the persistent var is not set, the pagelayout recalculates it for the needs of the subsequent included templates

    - it is not easy to have the persistent_var set from your own custom modules as it is from view/content
    - all the node/view/full tpls have had to be modified to include the calculation of the persistent var
    - understanding the relationship between expiry of the cache blocks in the pagelayout and persisnt_var persistence due to view cache is not trivial

    advantages: it looks like it is working ;)
  • Piotr Karaś
    Saturday, 26 April 2008, 18:56

    Persistent variables

    Thanks for the reply!

    Seems like there's a new thing to learn. I have seen this variable type mentioned somewhere, but never actually stopped to study it, and the documentation doesn't say much about it, either. Doesn't seem to be encouraged - why?

    So, this persistent variable - is it for given template or for given content? Does it expire upon publishing or is somehow node-related?

    Meanwhile, I will push my little idea ahead from time to time. I would like it to have the exact same expiry options that cache-blocks do, because I find cache blocks to be of completely different flexibility than view cache. The view cache usually does OK for itself, but I rarely have to cope with layouts as simple/ez-dedicated as eZ's defaults ;) And that's where those subtree-expiry and other options come quite handy.

    Unfortunately, I've received little interest and no direct feedback on my idea so far, regarding neither the extension nor the concept in general ;( Maybe it sucks...?

Log in or register to add a comment