Author
|
Message
|
Sébastien Antoniotti
|
Thursday 21 August 2008 7:39:39 am
I'm asking me about the use of cache-blocks and set-block. If the viewcaching is enabled, my views are cached that's OK. But in some cases, I don't want to cache all the module_result.content, by example if I want to display an attribute who's often modified without a republication of the content object. So my question is : did I need to start that sort of template by a {set-block scope=root variable=cache_ttl}0{/set-block} like this :
{set-block scope=root variable=cache_ttl}0{/set-block}
{cache-block}
{$node.data_map.title.content}
{/cache-block}
{$node.data_map.note.content}
{cache-block}
{$node.data_map.text.content}
{/cache-block}
or this directive is not mandatory and so I can do this and eZ Publish will cache only my cache blocks :
{cache-block}
{$node.data_map.title.content}
{/cache-block}
{$node.data_map.note.content}
{cache-block}
{$node.data_map.text.content}
{/cache-block}
Thanks in advance !
eZ Publish Freelance
web : http://www.webaxis.fr
|
Ivo Lukac
|
Thursday 21 August 2008 9:07:05 am
Hello, Yes, to disable view cache per file you must specify {set-block scope=root variable=cache_ttl}0{/set-block} at top of file.
http://www.linkedin.com/in/ivolukac
http://www.netgen.hr/eng/blog
http://twitter.com/ilukac
|
Piotrek Karaś
|
Thursday 21 August 2008 9:53:57 am
I'm not actually sure if cache-blocks should be used within viewcache-cached content result. Also, you can verify both your examples by adding: {currentdate()}
and seeing if it gets cached or not.
--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu
|
André R.
|
Thursday 21 August 2008 11:48:19 am
Piotrek: There are plenty of uses cases where you could use cache-blocks inside node templates, the most obvious would be when you need to disable view cache on a node because you do something in there that the view cache system doesn't support, for instance you fetch some data directly that is not really related to the current node.
But from my experience I would recommend to try to solve your solutions with the view cache system in mind, since you:
1. get less performance if you set cache_ttl=0 ( ref: http://issues.ez.no/IssueView.php?Id=13274&activeItem=18 ) 2. If you instead use related content ( embed, attribute or object relations ), your editors will be able to do changes instead of asking you every time. There are probably also uses cases where you can benefit from combining cache-blocks and view cache, but can't come up with any right now.
eZ Online Editor 5: http://projects.ez.no/ezoe || eZJSCore (Ajax): http://projects.ez.no/ezjscore || eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription
@: http://twitter.com/andrerom
|
Sébastien Antoniotti
|
Thursday 21 August 2008 12:29:28 pm
In my case, the $node.data_map.note attribute is an ezinteger increased via ajax directly on the data_int in the database. So to always get the note of the article "in live" I need to disable the viewcaching in my template and place all template code in cache-blocks except the note attribute output no ?
eZ Publish Freelance
web : http://www.webaxis.fr
|
Piotrek Karaś
|
Thursday 21 August 2008 1:14:05 pm
There are plenty of uses cases where you could use cache-blocks inside node templates, the most obvious would be when you need to disable view cache on a node because you do something in there that the view cache system doesn't support, for instance you fetch some data directly that is not really related to the current node.
Maybe I wasn't clear enough. I just thought cache-blocks should not be used inside viewcache (if it is on). In other words, for node templates you should <b>either</b> use view cache: {some node operations}
<b>or cache blocks:</b> {set-block scope=root variable=cache_ttl}0{/set-block}
{cache-block}{some node operations}{/cache-block}
<b>but never</b>: {cache-block}{some node operations}{/cache-block}
And if that's not the case - I'd be happy to learn. If there is no technical reasons not to embed cache block within viewcache, then I may definitely find use for those. So to always get the note of the article "in live" I need to disable the viewcaching in my template and place all template code in cache-blocks except the note attribute output no ?
In this case I would still apply viewcache there, with a named empty <div> element waiting for some dynamic content being injected later from within uncached part of pagelayout.
--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu
|
Sébastien Antoniotti
|
Thursday 21 August 2008 11:36:39 pm
In this case I would still apply viewcache there, with a named empty <div> element waiting for some dynamic content being injected later from within uncached part of pagelayout.
Sorry but I did not understand what you recommend to me... Thx
eZ Publish Freelance
web : http://www.webaxis.fr
|
Piotrek Karaś
|
Friday 22 August 2008 2:16:32 am
Ok, sorry. What we usually do in such cases is that we stick to viewcache, so no cache_ttl=0 and no cache-blocks in the node template. Instead, we place there an empty identified div: Some node content here...
<div id="my_dynamic_integer"></div>
Some more node content here...
This div tag will always be there waiting for its content. Then, later in the pagelayout code, after $module_result.content, in pagelayout part that is not cached in any way, we fetch the dynamic integer from whatever it is to be fetched, using whatever method is needed (let's say, a special template operator is there to consume a webservice that provides that integer). In the end, we generate a simple javascript code that will inject the fetched value into the known div: <script type="text/javascript" language="javascript">
document.getElementById( 'my_dynamic_integer' ).innerHTML = 'My fetched value=123';
</script>
This is maybe far from ideal, but the gain is a lightweight up-to-date piece of data combined with all the benefits of viewcache (including its performance and smart clearing rules). Hope this explains a bit ;)
--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu
|
André R.
|
Friday 22 August 2008 2:38:14 am
And if that's not the case - I'd be happy to learn.
If there is no technical reasons not to embed cache block within viewcache, then I may definitely find use for those.
There is no technical resons to not do so, so you can freely combine them. One use case would be a node that are frequently updated, and since it has a lot of trafic (frontpage / forum root page) you use cache blocks around some of the content so it' isn't re generated every time view cache is. > This div tag will always be there waiting for its content. I use the same approach to set user name on log out labels in custom projects since I personally think its a wast of server resources to 1 regenerate hughe amount of pagelayout pr user and 2. the extra disk space needed to keep cache blocks pr user. code in end of pagelayout:
{if $current_user.is_logged_in}
<script type="text/javascript">
<!--
(function(){ldelim}
var userNameTag = document.getElementById('currentusername');
if ( userNameTag ) userNameTag.innerHTML = "{$current_user.contentobject.name|wash}";
{rdelim})();
-->
</script>
{/if}
eZ Online Editor 5: http://projects.ez.no/ezoe || eZJSCore (Ajax): http://projects.ez.no/ezjscore || eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription
@: http://twitter.com/andrerom
|
Piotrek Karaś
|
Friday 22 August 2008 2:41:59 am
There is no technical resons to not do so, so you can freely combine them.
One use case would be a node that are frequently updated, and since it has a lot of trafic (frontpage / forum root page) you use cache blocks around some of the content so it' isn't re generated every time view cache is.
Exactly - thanks André!
--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu
|
Sébastien Antoniotti
|
Sunday 24 August 2008 2:00:56 am
So we can use cache-blocks inside a node template witout the set-block directive but only when parts of the template needs to be refreshed less often than the viewcaching cache ?
eZ Publish Freelance
web : http://www.webaxis.fr
|
André R.
|
Sunday 24 August 2008 3:47:04 am
> So we can use cache-blocks inside a node template without the set-block directive but only when parts of the template needs to be refreshed less often than the viewcaching cache ? Yes, in other words: > or this directive is not mandatory and so I can do this and eZ Publish will cache only my cache blocks : No, it it is mandatory if you want to disable view cache. But as we pointed out, performance wise not a good idea. So use some of many ajax / javascript trick to set the value from a place in pagelayout that is not cached or frequently updated.
In even other words: there are no connections between cache-blocks and view cache, they work independently from each other so you can freely combine them.
Note: But remember the rules of hierarchical caching, the outer most cache, will always 'rule' over the ones inside it. So a cache block inside a view cache (or another cache block) will not be refreshed before the outer cache is.
Note 2: There are a bit of overhead on cache blocks as well, so stuff like:
{cache-block}
{$node.data_map.title.content}
{/cache-block}
Will not make sense, since the cache block has more overhead then just displaying a single attribute. So only cache large sections of code that do slow stuff, like several connection to a database, heavy template operations(should be rewritten to template operator if you can) or retrieves data from another server and so on.
eZ Online Editor 5: http://projects.ez.no/ezoe || eZJSCore (Ajax): http://projects.ez.no/ezjscore || eZ Publish EE http://ez.no/eZPublish/eZ-Publish-Enterprise-Subscription
@: http://twitter.com/andrerom
|
Sébastien Antoniotti
|
Sunday 24 August 2008 12:32:22 pm
Thanks André, it's clearer ! A last one question : if I insert a cache-block without disabling viewcaching in a template, the cache-block expiration will not be visible as far as the object isn't updated/modified ?
eZ Publish Freelance
web : http://www.webaxis.fr
|
Piotrek Karaś
|
Sunday 24 August 2008 10:12:31 pm
A last one question : if I insert a cache-block without disabling viewcaching in a template, the cache-block expiration will not be visible as far as the object isn't updated/modified ?
That's right. As André has just written: "so a cache block inside a view cache (or another cache block) will not be refreshed before the outer cache is". In other words, cache-block rules will be checked each time the viewcache rules have forced viewcache for a node to be cleared. If view cache is there, nothing happens with cache-block. When view cache is gone, it will have to regenerate itself, and on its way to do so it will find cache-block definitions which it will have to process. If cache-blocks have expired for whatever reasons, they will be regenerated. If not, their HTML resulting code will be fetched and used.
--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu
|
Sébastien Antoniotti
|
Monday 25 August 2008 2:03:45 am
Thank you all for such explanations!
eZ Publish Freelance
web : http://www.webaxis.fr
|