Re: [Zope] Idea of Caching DTML Methods in Zope
Jaroslav Lukesh wrote:
Hi all,
I have idea about another caching method in Zope. I am very sorry if it exist, but I dont know that.
If I have for example very expensive or manytimes called method, I cannot cache it via RAM cache manager, because it gives the same output regardless place from where are calling.
For example, two methods:
siteroot <dtml-var BASE1>/
localroot <dtml-in "PARENTS[3:]">../</dtml-in>
(3 because I use virtual servers as zoperoot/www/domain )
So siteroot can be cached via RAM cache manager without no problems, because constructing URLs are
<dtml-var siteroot>images/imege.gif output will http://www.domain.com/images/imege.gif
But localroot could not be cached, because i receive bad locations:
<dtml-var localroot>images/imege.gif output will ../../images/imege.gif
If localroot are cached, then output of that will be same regardless of calling directory, it is computed from first access.
So it is possible to do "dynamic" caching? What I mean, is store all localroot objects in context of calling direcotry (or another object).
I have few hundreds of calling localroot per page and I will be hapy if it will have some solution for that. I dont want migrate to siteroot because it makes absolute URLs, not relative.
I know, I could use squid and Accelerated cache manager as reverse cache for caching whole pages, but it is not wanted solution (because you cannot see immediatelly changes to pages).
Many thanks for tips or implementation ;-)
Why not do <dtml-let my_localroot="PARENTS[3:]"> [use my_localroot 100 times] </dtml-let. But I suspect this is just because you gave a simplified example. See, the problem with your idea is more or less exactliy the same a with the squid solution: you will not see changes on a page immediatly, as the cached method can't really know if the context has changed (in case of your local_root thingy, what happens if you have changed the id of a folder higher up? Actually, because Accelerated Cache Manage can purge pages on the proxy, I think the solution you can get with squid is exactly the same as with your proposed solution - just some magnitudes faster. cheers, oliver
participants (1)
-
Oliver Bleutgen