Flat PHP Legacy App - How to wrap in silex routes - php

Question

I have been tasked with finding a solution to wrapping a custom made application in the silex framework as they are going to continue forward using silex. The dilemma is the legacy application is a flat php style with no controllers or models, and php with mysql queries embedded within the via files.
I have been struggling to find any clean solution to wrap the legacy app in the routing of silex to allow for new portions to be done in a controller based setyp instead of flat php. I have been checking for some time between stack overflow and other Google results, but they an del seem to end up specifying ways of doing default routes with a legacy app that has a controller based setup.
For good measure, the legacy app does use session variables so the solution must allow for those to be used.
Any and all help is appreciated.
Before people ask, I have looked at Routing in Silex/Symfony - Providing a default route and it is similar to how I would like to do it, but I need to make it work with the flat php app, not legacy controllers.

Answer 1

The solution ended up being a 2 part process.
Place the legacy code within the web root of the silex application.
Get the silex application to store sessions that are accessible by both Silex, and the legacy application.
Code Placement
By placing the legacy code into the web folder, anything in the URL that matches a file will go to that file instead of looking for a route. This allows for not needing to create routes for all of the old code, as it is not controller based in our situation and needs to be handled differently than most of the other restructuring that has been referred to on this site.
Placing the code into the web directory also means that we can continue to make updates and changes to the old code, while writing new Silex based code to replace it in our available time.
Sessions
When it came to using the same sessions, the option we went with was....less than desirable, but it allows for us to continue with our plans without hindering the use of either application. The current plan is to implement database stored sessions once we have completed migrating the application's code to Silex.
We went with an option first identified in this post Symfony session avoid _sf2_attributes. This is quite an ugly solution, but allows for the flexibility we need in attempting to migrate the application over in time with minimal effort up front. The goal is to migrate it over completely to the new Silex application, but the timeframe is over a year or more to do so.
Here is how the session is configured in our Silex application. It is using file based storage.
$app->register(new Silex\Provider\SessionServiceProvider(), array(
'cookie_lifetime' => 86400,
));
$app['session.storage'] = $app->share(function () use ($app) {
return new \Symfony\Component\HttpFoundation\Session\Storage\LegacySessionStorage;
});
Here is a copy of the controller code located originally here, in case it is removed at some point.
<?php
use Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage;
/**
* Session sotrage that avoids using _sf2_attributes subkey
* in the $_SESSION superglobal but instead it uses
* the root variable.
*/
class LegacySessionStorage extends NativeSessionStorage
{
const SYMFONY_SESSION_SUBKEY = '_sf2_attributes';
/**
* #inheritdoc
*/
protected function loadSession(array &$session = null)
{
if (null === $session) {
$session = &$_SESSION;
}
parent::loadSession($session);
foreach ($this->bags as $bag) {
$key = $bag->getStorageKey();
if (self::SYMFONY_SESSION_SUBKEY === $key)
{
$bag->initialize($session);
}
}
}
}
I hope this helps some others in allowing them to migrate to a new coding style from an old application that is a thorn in their side. Wanted to make sure to sum up our findings over time in order to ensure others don't have to look as much in the future hopefully.

Answer 2

there is a really good article written by Matthias Noback about this. Basically the trick would be to match the legacy urls and return the legacy output inside a Silex Response object. Beware of memory use with ob_* methods.

Answer 3

An alternative is to modernize the flat PHP application in place (leaving you with one unified codebase) instead of wrapping it (which leaves you with 2 codebases). The step-by-step details are in Modernizing Legacy Applications in PHP but the overview is this:
Implement an autoloader
Consolidate classes and functions to a central location
Remove globals in favor of dependency injection
Remove the new keyword in favor of dependency injection
Write unit tests
Extract SQL code to Gateway classes ("Model, Part 1")
Extract domain logic to Transaction classes ("Model, Part 2")
Extract presentation logic to Response classes ("View")
Extract action logic to Controller classes ("Controller")
Extract remaining includes
Extract application code from the document root
Implement a front controller
Prepare the application for a dependency injection container
Add a dependency injection container
Hope that helps.