Silex

The problem: routing /blogs, not just /blogs/ in Silex

Route mounting in the Silex PHP framework allows conveniently grouping controllers per feature in separate files, then using mounting them on some prefix path like $app->mount('/blogs'). This will prepend the prefix "/blogs" to the paths defined in the the feature controller, effectively delegating to it all the /blogs/* routes. However, as the Silex documentation claims:

When mounting a route collection under /blog, it is not possible to define a route for the /blog URL. The shortest possible URL is /blog/.

This means handling the route mount point has to be done by a route outside the mounted feature, which makes it slightly less clean, as you have to do something like:

<?php$blog = require_once __DIR__ . '/controllers-blog.php';// This will handle /blogs/ and below, but not /blogs$app->mount('/blogs', $blog);// So we have to use a non-mounted route from a sub-request to avoid a redirect().$app->get('/blogs', function () use($app) {   // forward to /blogs/   $subRequest = Request::create('/blogs/' , 'GET');   return $app->handle($subRequest , HttpKernelInterface::SUB_REQUEST);}?>

But is there really no workaround for this limitation ? Sure there is!

A few days ago, while I was writing a bit of Silex code and grumbling at Doctrine DBAL's lack of support for a SQL Merge operation, I wondered if it wouldn't be possible to use DBTNG without the rest of Drupal.

Obviously, although DBTNG is described as having been designed for standalone use: DBTNG should be a stand-alone library with no external dependences other than PHP 5.2 and the PDO database library, in actual use, the Github DBTNG repo has seen no commit in the last 3 years, and the D8 version is still not a Drupal 8 "Component" (i.e. decoupled code), but still a plain library with Drupal dependencies. How would it fare on its own ? Let's give it a try...

The WebProfilerServiceProvider brings the Symfony Profiler to Silex apps, and with it the nice "Timeline" feature, detailing for each request cycle the time spent handling each event dispatched by the EventDispatcher, from kernel.request to kernel.terminate, with detail time spent in each individual listener.

The timeline looks like this one:

This is all nice and well, but there is a problem with this timeline: although the beginning and end of the request cycle is profiled in depth, it represents less than half of the total time spent for this request.

More than half of the total request time is spent in the controller, and this example does not even perform any database access, which would make the controller represent event more of the total time, making the detailed analysis of the beginning and end of the request cycle less relevant.

What would make sense would be to subdivide the time spent in the controller in much the same way the time spent in the event listeners is already plotted. Is there a simple way ? Sure: let us see how the profiler works.