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

Question

J'ai une grande application web fonctionnant en Perl CGI. Ça marche bien, c'est bien écrit, mais comme c'était le cas dans le passé, tous les html sont codés en dur dans les appels CGI, comme vous pouvez l'imaginer, il est difficile de le maintenir, de l'améliorer et ainsi de suite. pour ajouter quelques modèles et intégrer avec un framework (catalyseur ou application CGI ::). Ma question est la suivante: Quelqu'un ici a une expérience comme celle-là? Il y a des choses pour lesquelles 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 exécuter les deux (code natif CGI "frameworked") ensemble sans aucun traumatisme. Des conseils?

Answer 1

Ensuite, quand vous changez des choses, vous savez toujours si quelque chose se brise, et ce qui casse.

Ensuite, extrayez le HTML dans des modèles et des sous-modules couramment utilisés dans les modules. Après c'est un morceau de gâteau pour passer à un cadre.

En général, allez pas à pas pour avoir toujours une application fonctionnelle.

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 ceux-ci sont candidats pour devenir des variables de modèle. Séparez cela en un fichier HTML, avec les parties identifiées marquées par des variables de modèle. Finalement, vous serez en mesure de refactoriser la page de sorte que tout le traitement est fait au début du code et le modèle HTML vient d'être appelé à la fin de tout le traitement. Ecrivez les tests d'abord (par exemple avec Test::WWW::Mechanize).

Answer 3

Dans ce genre de situation, à la base de la réécriture, 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, en fonction de combien 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 devez probablement creuser plus profondément dans le "pourquoi?" et ce sera probablement quelque chose d'étrange, ça n'a pas de sens à première vue. Une chose à ne pas oublier est de savoir si quelqu'un a fait quelque chose de similaire dans le framework que vous utilisez. Vous pourriez vous épargner 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 d'importance:

1. séparés HTML et le code dans des fichiers distincts. J'ai utilisé un moteur de modèle pour cela.
2. Création fonctions à partir du code qui a rendu un modèle avec un ensemble de paramètres.
3. Organisé les fonctions (que j'ai appelé vues, inspiré par Django) d'une manière sensible. (Vues Admin, vues de l'utilisateur, etc.) Les vues tous suivent la même convention d'appel!
4. refactorisé la base de données et demande des choses afin que les vues ne contiennent que vue code spécifique (lire: Manipulation GET, POST des demandes, etc., mais rien de bas niveau). S'appuyer fortement sur les bibliothèques existantes pour cela.

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

• un répartiteur Ecrire qui mappe URL à vos vues. Cela conduira également à des URL plus belles et à une meilleure gestion des erreurs et des erreurs.

Answer 5

L'une des hypothèses que les frameworks font est que les urls correspondent au code. Par exemple, dans un cadre, vous verrez souvent les éléments suivants:

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

Habituellement, si les anciens scripts CGI ne fonctionnent pas comme ça, vous êtes plus susceptibles d'avoir quelque chose comme:

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

Pour profiter du framework, vous devrez peut-être changer toutes les URL. Que vous puissiez le faire et que vous conserviez le bon fonctionnement des anciens liens, cela peut constituer une grande partie de votre décision.

De même, les frameworks prennent en charge une sorte de ORM (Object Relational Mapper) qui permet d'abstraire les appels de la base de données et de gérer uniquement les objets. Pour Catalyst, il s'agit généralement de DBIx::Class. Vous devriez évaluer ce que le coût de passer à ce sera.

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