Add a {cache-block} statement inside your foreach loop, using node_id as key.
Take care about your objects being modified, though: the cache block might not be expired automatically (read up the onlinde docs about cache blocks for more details)
Principal Consultant International Business
Member of the Community Project Board
I have only tested it superficially, but it seems to work and give good speed increase compared to uncached version. I do need a {set-block scope=global variable=cache_ttl}0{/set-block} on top though. Probably because I need the list to be updated when children of children are being changed.
One short question, is using $node.url a good way to set subtree_expiry?
That might work, but it kind of looks like a hack. Next time you think about implementing stuff like this, use relations (object or attribute) or structure, then the Content View Cache system is able to clear the cache for you when content is edited meaning you don't need to use cache_ttl=0.
Using $node.node_id should also work as subtree_expiry key.
The ttl=0 on top is there because otherwise the whole template will only be executed when the current node changes and its result stored in the view cache. It will thus not be updated anytime any of the included object or their subchildren change.
I fully agree with Andre that it looks ugly though: using object relations is the best way to get proper change propagation within eZ view caches.
Last but not least, the main question, that has been left unsaked: how comes the standard view cache is not enough for your needs?
I can imagine 2 reasons:
- the list of nodes included in the loop is huge
- the templates used to display those nodes are inefficient Maybe you should look into refactoring somewhere else and not just adding caches...
Principal Consultant International Business
Member of the Community Project Board
You must be logged in to post messages in this topic!
