twigphp
Support for setting output variables from inside cache blocks
Feature: https://twig.symfony.com/doc/3.x/tags/cache.html
Often when working with cache in templates you'd like to define variables that are persisted to scope outside cache block, both when generated and later when retrieved from cache.
Examples can be many, but one would be passing FosHttpCache tags to it's Response cache tagging system based on what is being displayed inside the the cached twig block.
cc @bdunogier
I don't see how this would work if you want the variable assignments to be persisted when the cache is used.
@stof In short the cache would need to contain more than just the static dump of the html, it will also need to be able to contain output variables, could be hash or other way to separate from the stack html dump. These could and should be limited to only allows scalars to avoid misc issues with objects (state, serialization, size, ...).
These could and should be limited to only allows scalars to avoid misc issues with objects (state, serialization, size, ...).
that would be a pain to implement, because it would require to detect which part of the context need to be stored (as such restriction cannot be applied to all variables)
that would be a pain to implement, because it would require to detect which part of the context need to be stored (as such restriction cannot be applied to all variables)
Sounds like you are assuming I imply storing all variables in context, I don't. Like on #3468 I suggest there should be a way to explicitly specify inside the block what variable you want to export. I didn't go into how, could be a function.
It would be relative simple to make sure a function only takes scalars, or?
Either way both these proposals would need to take nested cache blocks into account.
doing changes from inside the body of a tag that impacts the tag itself is a huge pain (we saw it for the {% break %} support in #3395). This creates requirements on all the nodes of the AST between both tags to ensure they don't isolate the compiled code from the parent, which is hard to maintain (especially when tags are an extension point of Twig and so the core does not know them all).
Ok I see. Sorry but then it seems you are jumping way too much into pain points of current implementation on a feature discussion, which is mot really relevant on feature level discussion.
Ignore that I mention functions or whatever, point here is to be able to manage (example) response changes inside cache blocks in some kind of way. In the other issue point is to be able to somehow say what tags are relevant at cache storage time, just like tags are used with Symfony Cache pool. How this is done I don't intend to put constraints on.
@andrerom be it functions or another syntax is not relevant here. My comment is about the pain of impacting the behavior of a tag (which is the case here as cache tags are applied by the cache as it is the one managing the cache item) from inside the body. That applies to any syntax doing that, and changing that fact would require rearchitecturing Twig from scratch (and I don't have an idea about an architecture that would make that easy while keeping tags as extension points of the language btw).