Quelle est la meilleure approche pour migrer un CGI vers un cadre?

Question

J'ai une grande application Web s'exécutant dans perl CGI. Il fonctionne bien, il est bien écrit, mais comme cela a été fait dans le passé, tous les html sont définis en code dur dans les appels CGI, donc, comme vous pouvez l'imaginer, il est difficile de garder, d'améliorer, etc. Alors, j'aimerais commencer ajouter des templates et intégrer dans un framework (catalyseur ou CGI :: application). Ma question est la suivante: quelqu'un ici a une expérience comme celle-là? Il y a des choses que je dois faire attention? Je suis conscient qu'avec les deux frameworks, je peux exécuter des scripts CGI natifs, donc c'est bien parce que je peux les exécuter ensemble (code "frameworked") avec une annonce native CGI sans aucun traumatisme. Des conseils?

Answer 1

Commencez par rédiger les tests (par exemple, avec Test :: WWW: : Mécaniser ). Ensuite, lorsque vous changez les choses, vous savez toujours si quelque chose se brise et ce qui le brise.

Extrayez ensuite le code HTML dans des modèles et les sous-fichiers couramment utilisés dans des modules. Après cela, il est très facile de passer à un framework.

En général, procédez étape par étape pour que votre application fonctionne toujours.

Answer 2

Extrayez le code HTML de la logique de traitement dans le script CGI. Identifiez tout le code qui affecte la sortie HTML, car ils peuvent devenir des variables de modèle. Séparez cela dans un fichier HTML, avec les parties identifiées marquées avec des variables de modèle. Vous pourrez éventuellement refactoriser la page de sorte que tout le traitement soit effectué au début du code et que le modèle HTML qui vient d'être appelé à la fin du traitement.

Answer 3

Dans ce genre de situation, en réécrivant à partir de rien, l’ancien code est utile pour A) les tests et B) les détails de conception. Idéalement, vous feriez un ensemble de tests, pour toutes les fonctionnalités de base que vous souhaitez répliquer, ou au moins des tests qui analysent les pages de résultats finaux afin que vous puissiez voir que le nouveau code renvoie les mêmes informations pour les mêmes entrées.

Les détails de conception dans le code peuvent être inutiles, selon le nombre de fois que le cadre gère automatiquement. Si vous avez un bon ensemble de tests et qu'une conversion simple fonctionne bien, vous avez terminé. Si le comportement du nouveau ne correspond pas à l'ancien, vous aurez probablement besoin de creuser plus profondément le "pourquoi?" et ce sera probablement quelque chose de bizarre, ça n'a pas de sens à première vue.

Une chose à ne pas oublier est d’abord de vérifier si quelqu'un a créé quelque chose de similaire dans le cadre que vous utilisez. Vous pourriez économiser beaucoup de temps et d'argent.

Answer 4

Voici comment je l'ai fait en utilisant Python au lieu de Perl, mais cela ne devrait pas avoir d'importance:

1. HTML et code séparés en fichiers distincts. J'ai utilisé un moteur de modèle pour cela.
2. Création de fonctions à partir du code qui a restitué un modèle avec un ensemble de paramètres.
3. Organisez les fonctions (que j’ai qualifiées de vues , inspirées de Django) de manière judicieuse. (Vues administrateur, vues utilisateur, etc.) Les vues suivent toutes la même convention d'appel !
4. Refactored la base de données et les requêtes afin que les vues ne contiennent que du code spécifique à la vue (lire: Gestion des requêtes GET, POST, etc., mais rien de bas niveau !) Nous avons beaucoup utilisé les bibliothèques existantes pour cela.

Je suis ici pour le moment. :-) La prochaine étape évidente est bien sûr:

• Écrivez un répartiteur qui mappe les URL sur vos vues . Cela conduira également à des URL plus agréables et à une gestion plus précise des erreurs et des erreurs.

Answer 5

L’une des hypothèses formulées par les frameworks est que les URL sont associées au code. Par exemple, dans un cadre, vous verrez souvent ce qui suit:

http://app.com/docs/list
http://app.com/docs/view/123

Habituellement, même si les anciens scripts CGI ne fonctionnent pas comme cela, vous aurez probablement quelque chose comme:

http://app.com/docs.cgi?action=view&id=123

Pour tirer parti du cadre, vous devrez peut-être modifier toutes les URL. Que vous puissiez le faire et comment vous maintenez les anciens liens en bon état peut constituer une part importante de votre décision.

De plus, les frameworks fournissent un support pour une sorte de ORM (Object Relational Mapper) qui résume les appels de base de données et vous permet de ne traiter que des objets. Pour Catalyst , il s’agit généralement de DBIx :: Class . Vous devriez évaluer le coût de ce changement.

Vous constaterez probablement que vous souhaitez effectuer une réécriture complète, avec l'ancien code comme plate-forme de référence. Cela peut être beaucoup moins de travail que prévu. Cependant, commencez par quelques sites de jouets pour avoir une idée du cadre / orm / modèle avec lequel vous décidez de vous lancer.