On 21.11.2010, at 18:08, Jordi Boggiano wrote: > On Sun, Nov 21, 2010 at 5:20 PM, Lukas Kahwe Smith <[email protected]> > wrote: >> thinking about it .. i might be assuming to much about ESI here. my >> assumption was that if i have multiple ESI tags generated by one controller >> and the ESI caching layer needs to get only a few of them re-generated, then >> i could somehow skip re-generating the content in the ESI tags where the ESI >> cache still has non stale data. > > Afaik, if you do <esi:include> in your page, the reverse proxy will > fetch that page as a secondary page request, so you can't just have > the framework render multiple esi:include tags at once. Therefore the > controller can do all the model fetching work it wants, since it won't > even be called if that particular resource is already cached.
right .. but the question is does the request know which ESI block it had to actually generate? aka you have ESI block's A, B, C on the same page foo. so if block B is out date, it will request page foo. does that request know that it actually only needs to generate B? i would imagine that you could embed this information inside the ESI src and then when you use twig for example it would not even bother generating ESI tag A and C for the request that is only done to full up the cache for ESI tag B. i guess i need to read the spec, because i dont really grasp how this all works in detail from Fabien's slides or the various pages i found about ESI. regards, Lukas Kahwe Smith [email protected] -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
