Custom template resolvers and digest caching. #36
Comments
|
Cache digests have been rolled into Rails. So it's the same code base. In your case, I would just add an md5 of the runtime template to the cache key itself. That's all Rails does anyway. So <% cache person, custom_template.md5 do %>. On Feb 26, 2013, at 4:31 AM, Daniel Schierbeck notifications@github.com wrote:
|
I'm running into an issue that makes it hard to use Cache Digests in some cases. In the app I'm working on, users can upload custom templates. When these templates are rendered directly as views, Cache Digests works fine -- the template is resolved by a custom resolver, and the template handler injects a cache call that includes the template's digest (computed separately) in the cache key. This trick doesn't work if the custom template is rendered as a partial, as it is assumed that a template does not change at runtime.
I can get around this by disabling caching of digests -- then all templates are loaded and their digests computed. I could even get rid of my custom digest hack that predates Cache Digests. However, this would impact performance.
If Cache Digests included the view path in the cache keys, I think the issue would go away. We could ask each resolver in the path for a cache key and include them in the final cache key. That way, my custom resolver could just check if there have been any changes to the templates since last time and compute a cache key accordingly.
Is this something you would be interested in having in Cache Digests? It feels like it would touch too deeply into Rails, so perhaps it should just go there instead.
The text was updated successfully, but these errors were encountered: