Fabien Potencier has new post post to the Symfony Blog today talking about a big update to the Symfony framework, the introduction of a new "fragment sub-framework". This framework (now a part of the HttpKernel) allows the handling of requests based on a few different strategies.

About a month ago, I merged a complete refactoring of the sub-requests management of Symfony. In fact, I created a whole new sub-framework to handle the rendering of resource fragments via different strategies. [...] Besides classical master requests, the HttpKernel component is now able to handle sub-requests. Let's me sum up the different strategies that are available: internal sub-requests, ESIs, HIncludes, and SSIs (in 2.3).

He talks some about each strategy and what situations they're best suited for and some sample code that shows the use of the "standalone" and "strategy" parameters. There's also new methods you can call (like "render_esi" or "render_hinclude") to work with the new features as well.

On the Procurios blog today there's a new post talking about a different sort of way to optimize your site's perfomance - fragment caching.

So if web caching is not an option, what is the next best thing? To cache parts of the page, put them together, and serve that. You can use a caching tool for this, like Memcached. There's only one catch: the cached content may need to change when any of the things it depends on changes: data, code, user input, and the like. You can pass an expiration time when you add your content to Memcache. This will cause your cache to live only a certain amount of time and then expire. Nice, but we can do better.

The method he talks about involves expiring the cached data when the dynamic data it comes from has expired rather than setting an expiration time on the data itself. Each time the data its pulled/rendered, the cached data is checked and is updated if the need is there. You're not so much checking for a valid cache as you are forcing an update when needed. There are some side effects mentioned like more database load and increased server load because of the data generation each time.

Code examples are included in the post that use this caching library to get the job done. You can also see how it works in the test file using that library.

In trying to convert over several HTML pages to the DITA XML format, James Edwards came up against a problem involving recursion:

But a problem I came across several times was the sheer complexity of recursive element conversion — <code> becomes <jsvalue> (or one of a dozen similar elements), <a> becomes <xref> … and that's all simple enough; but each of these elements might contain the other, or further child elements like <em>, and as we walk through the DOM so the incidence of potential recursion increases, until it gets to the point where my brain explodes.

His solution involves working with both regular expressions and document fragments. He loads the node he wants to work with, its parsed to prepare it and is passed off to do the "text-based mangling" to update it. The result is them pushed back into an XML object (fragment) and this is pushed back into the main document with a replaceChild call.