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). The order issue might not be too dramatic because variables defined in one block are not accessible in later blocks, only in child blocks, much like JS scopes/closures. 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. 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. Of course this could be made optional, so that if you need complex output filtering, you could just keep buffering until the end. Cheers -- Jordi Boggiano @seldaek :: http://seld.be/ -- 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
