Dopez vos anciens sites au fur et à mesure

Aujourd’hui, je ne vous apprends rien, le développement web s’est considérablement professionnalisé et on ne fait plus de sites web comme on les faisait il y a 10 ans. Mais pourtant il y a bien des sites web qui ont encore 10 ans et n’ont jamais été refondu.

Pourquoi refondre quelque chose qui fonctionne me direz-vous ? Oui bonne question ! La principale me semble la maintenance et l’évolution du site qui devient au fil des années, compliquée voir quasi impossible.

Mais refondre un site from scratch n’est pas de tout repos et finalement peut-être pas la meilleur idée. Du coup, nous allons voir un cas pratique de migration en douceur d’un site “old scool”.

Le contexte

Nous parlons d’un site ici où chaque page web est représentée par une page php. Pas de rewrite. Chacune faisant un nombre incalculable de require, include, echo. Où beaucoup de développeurs sont passés par là, chacun sur le temps perso, pour la plupart le développement étant un loisir.
Pas la peine de vous faire un dessin, vous voyez le tableau.

L’objectif

Mettre en place une pseudo v2 progressive :
Recréer chacune des pages sur un nouveau socle applicatif plus actuel puis optimiser l’ensemble une fois toutes les pages crées. Les anciennes pages, doivent fonctionner avec les nouvelles sans changement dans les premières. En gros, tout le monde ne doit y voir que du feu.

Fonctionnement

Pour réaliser ça, je me suis pas foulé, je me suis tout simplement inspiré de ce que Fabien avait pris le temps de mettre par écrit dans sa série : “Create your own Framework”.

Du coup c’est plus la mise en pratique que je vais détailler. Nous allons donc migrer une page qui s’appelle : rechercheJoueur.php

Première étape, configurer notre nouvelle app en créant un fichier v2.php à la racine de notre serveur (vu que le vhost pointe ici) et contenant le code de l’étape 5 de fabien.
A partir de là, on a déjà quelque chose de sympa et quasi prêt à emploi. Faisons le test.

Dans notre app.php on va donc déclarer en route la première page qu’on va migrer. Genre ça:

<?php
use Symfony\Component\Routing;
 
$routes = new Routing\RouteCollection();
 
$routes->add('search', new Routing\Route('rechercheJoueur.php', array(
    '_controller' => 'render_template',
)));
 
return $routes;

On va c/c le contenu de notre ancienne page dans le dossier src/pages définies dans la fonction render_template en prenant soin de la renommer par search.php (nom de la route).

A ce niveau bien sûr, si vous accédez à l’ancienne url, vous tombez toujours sur l’ancienne page.
Nous allons donc créer un .htaccess à la racine avec tout simplement :


    RewriteEngine On
    RewriteBase /

    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^(.*)$ v2.php [QSA,L]

Pas besoin de grand discours, en gros, tout les urls qui ne pointent pas sur une ressource existante, iront maintenant sur notre nouvelle application.

Renommons maintenant notre ancienne page. Et tentons d’y accéder (par son ancien nom) et magie, on pointe désormais sur la nouvelle page qui doit se comporter exactement comme l’ancienne vu que finalement, on a pas changé grand chose pour l’instant.

Mais le principal avantage c’est que toutes nos pages passent par le même endroit désormais.

Du coup la prochaine étape, est celle décrite dans la partie 6, utiliser HttpKernel et son ControllerResolver pour utiliser des controller en lieu et place de notre function render_template.

On pourra alors sortir tout le code php de notre page à migrer, et le mettre dans le controller en 1ere étape de séparation du code php / html.

Je me suis ensuite arrêté là niveau applicatif. J’ai trouvé que j’avais tous les éléments à ma disposition. Mais n’hésitez pas à continuer la suite de la série de Fabien.

Du coup, au lieu du DIC de Symfony2 dont Fabien parle dans l’étape 12, j’ai personnellement opté pour Pimple vu que le site n’est vraiment pas compliqué niveau technique et que je n’avais pas besoin de l’artillerie lourde de ce côté.

Du coup, j’ai injecté dans Pimple, une connexion DBAL de doctrine et twig comme moteur de template et j’ai décidé d’injecter directement tout ce container dans tous mes controllers (même si on est d’accord que c’est le mal) mais en l’état c’est pas vraiment problématique j’ai juste 2 services.

Du coup j’ai un peu modifié la partie concernant l’appel au controller dans mon v2.php pour reproduire le setContainer propre au ContainerAwareInterface mais qui attend un ContainerInterface du DIC. Pour utiliser Pimple dans nos containier, il faut donc reproduire ce setContainer.

try {
    $request->attributes->add($matcher->match($request->getPathInfo()));
 
    $controllers = $resolver->getController($request);
    // on instancie notre controller 
    $controller = new $controllers[0];
    // on récupère l'action
    $action = $controllers[1];
    // On injecte Pimple
    $controller->setContainer($container);
    // On récupère les arguments
    $arguments = $resolver->getArguments($request, $controllers);
 
    $response = call_user_func(array($controller, $action), $arguments);
} catch (Routing\Exception\ResourceNotFoundException $e) {
    $response = new Response('Not Found', 404);
} catch (Exception $e) {
    $response = new Response('An error occurred', 500);
}

Voilà, un peu brut, mais ca fait son job rapidement. Il suffira de créer un controller qui contiendra cette méthode setContainer et dont tous nos controllers hériteront. Et nous pourrons alors utiliser notre dbal et notre twig dans nos actions !

La suite n’est que du refactoring du code existant. Faites déjà fonctionner une page, essayant de découper les traitements dans des classes adéquates. Chaque nouvelle page, apportera son lot de cas particulier, mais plus ça ira et plus ce sera simple de migrer les pages.

Et ensuite ?

Je n’y suis pas encore, mais j’imagine qu’une fois qu’on s’est affranchi des contraintes de l’ancien système, on peut commencer à optimiser un peu, créer une couche modèle, peut-être envisager un ORM ? Ou tout simplement se dire, que c’est bien suffisant et que maintenant, n’importe quel dev avec une connaissance du MVC devrait pouvoir utiliser et maintenir le code ! Et c’était quand même l’objectif ;)

Tags: , , ,

A propos de l'auteur

Développeur web spécialisé Symfony, il est avant tout passionné de web tout simplement. Il aime les défis et farfouiller dans le code de Symfony ou Doctrine. Fondateur du blog, il exerce chez Autrement.

Vous avez aimé ce billet? Faites le savoir!

  • Delicious
  • Twitter
  • Technorati Favorites
  • FriendFeed
  • Google Bookmarks
  • Share

Les commentaires sont fermés.