当谈到使用相同的会话时,我们选择的选项是......并不理想,但它允许我们继续我们的计划,而不会妨碍任何一个应用程序的使用。目前的计划是在完成将应用程序的代码迁移到Silex后,实施数据库存储的会话。
我们带着这个帖子中第一个标识的选项Symfony session avoid _sf2_attributes。这是一个相当丑陋的解决方案,但可以在尝试以最小的努力及时迁移应用程序时提供所需的灵活性。我们的目标是将其完全迁移到新的Silex应用程序,但时间跨度超过一年或更长。
这是在我们的Silex应用程序中如何配置会话。它使用基于文件的存储。
$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控制器代码,在情况下,它是在某一时刻除去的副本。
<?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);
}
}
}
}
我希望这可以帮助其他一些人,让他们从旧的应用程序,是他们的眼中钉迁移到新的编码风格。希望确保总结我们的研究结果,以确保其他人不必在未来看起来像希望一样。