On 19.11.2010, at 15:18, Jordi Boggiano wrote: > On Fri, Nov 19, 2010 at 8:12 PM, Lukas Kahwe Smith <[email protected]> > wrote: >> now once you are inside a twig template you have stuff like blocks and >> extends. so with twig it should be possible to travel upto the most outer >> extend. we could also make it possible to "tag" blocks, f.e. "javascript", >> "css", .. now in the most outer layout we can then have "yield" calls that >> basically say if all blocks tagged with the given yield label have been >> processed, then flush up to this point. >> >> so essentially twig could process blocks inside the templates in a different >> order than like they are actually defined in order to more quickly be able >> to push out content. the blocks would each "pull" in the content that they >> need, thereby delaying expensive calls as long as possible. > > For frontend (and I mean *in the browser*) performance, what matters > is that the head tag is output as soon as possible, and it must > contain all stylesheets to make this worthwhile. The rest of the page > is less critical because when head is received the browser will start > fetching stylesheets and attached dependencies (images).
right .. it might make sense to have a simple solution for just this use case. i guess the chances are low that someone wants to implement some long polling solution on top of sf2. > The main thing that made me drop the ball on this is that given the > way Symfony2 handles requests, you need a fully populated response > object at the moment for output to even begin. It is then passed to > that core.response event/filter, which means the output could be > modified there. Right, chunked response will probably make some magic impossible. but it seems like an important enough use case to at least optionally support out of the box. > The only solution I see, and I'm really not sure how feasible it is, > is to have "streaming" request objects, that would just dispatch an > event every time they're flushed (or yield), and that would dispatch > core.response on the current output so it can be filtered. It would > however mean that output filters would have to be able to handle html > fragments and not a full page tree at once. It doesn't sound too > impossible, but I haven't looked in detail at the current > implementation. right .. all filters would need to be aware of the output mode and they should probably receive some context information in order to know at which "step" of the response its being called. maybe filters for this streaming response would actually be registered on the "step" in order to prevent too much overhead being introduced by repeatedly triggering all filters. 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
