Flat PHP Legacy App - 如何包装在silex路由中

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.

1. Place the legacy code within the web root of the silex application.
2. 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.