Was ist der beste Ansatz, um ein CGI zu einem Framework zu migrieren?

Schreiben Sie zuerst Tests (zum Beispiel mit Test::WWW::Mechanize ). Dann, wenn Sie Dinge ändern, wissen Sie immer, wenn etwas bricht, und was es ist, das bricht.

Entpacken Sie anschließend HTML in Vorlagen und häufig verwendete Subs in Module. Danach ist es ein Kinderspiel, zu einem Framework zu wechseln.

Im Allgemeinen gehen Sie Schritt für Schritt, so dass Sie immer eine funktionierende Anwendung haben.

Extrahiere den HTML-Code aus der Verarbeitungslogik im CGI-Skript. Identifizieren Sie den gesamten Code, der sich auf die HTML-Ausgabe auswirkt, da dies Kandidaten für Vorlagenvariablen sind. Trennen Sie das in eine HTML-Datei, wobei die identifizierten Teile mit Vorlagenvariablen markiert sind. Schließlich können Sie die Seite so umgestalten, dass die gesamte Verarbeitung am Anfang des Codes erfolgt und die HTML-Vorlage am Ende der Verarbeitung aufgerufen wird.

In dieser Art von Situation, die grundsätzlich von Grund auf neu geschrieben wird, ist der alte Code nützlich für A) Tests und B) Design-Details. Im Idealfall würden Sie für alle Basisfunktionen, die Sie replizieren möchten, eine Reihe von Tests durchführen oder zumindest Tests durchführen, bei denen die endgültigen Ergebnisseiten analysiert werden, damit Sie sehen können, dass der neue Code dieselben Informationen für dieselben Eingaben zurückgibt.

Entwurfsdetails innerhalb des Codes sind möglicherweise nutzlos, abhängig davon, wie viel das Framework automatisch verarbeitet. Wenn Sie eine gute Auswahl an Tests haben und eine einfache Konvertierung gut funktioniert, sind Sie fertig. Wenn das Verhalten des neuen nicht mit dem alten übereinstimmt, müssen Sie wahrscheinlich tiefer in das "Warum?" und das wird wahrscheinlich etwas seltsam aussehen, das macht auf den ersten Blick keinen Sinn.

Eine Sache, an die Sie sich zuerst erinnern sollten, ist herauszufinden, ob jemand in dem von Ihnen verwendeten Framework etwas Ähnliches gemacht hat. Sie könnten sich eine Menge Zeit und Geld sparen.

Hier ist, wie ich es mit Python anstelle von Perl gemacht habe, aber das sollte keine Rolle spielen:

1. HTML und Code wurden in verschiedene Dateien getrennt. Ich habe dafür eine Template Engine verwendet.
2. Erstellt Funktionen aus dem Code , die eine Vorlage mit einer Reihe von Parametern erstellt haben.
3. Organisierte die Funktionen (die ich Ansichten , inspiriert von Django) auf eine vernünftige Art und Weise. (Admin-Ansichten, Benutzeransichten usw.) Die Ansichten folgen alle derselben Aufrufkonvention !
4. Die Datenbank wurde refactored und Objekte angefordert, so dass die Ansichten nur sichtspezifischen Code enthielten (lesen Sie: GET, POST-Anfragen usw., aber nichts Low-Level) !). Darauf stark für vorhandene Bibliotheken angewiesen.

Ich bin im Moment hier. :-) Der nächste naheliegende Schritt ist natürlich:

• Schreiben Sie einen Dispatcher , der URLs Ihren Sichten zuordnet. Dies wird natürlich auch zu schöneren URLs und einer besseren 404- und Fehlerbehandlung führen.

Eine der Annahmen, die Frameworks treffen, ist, dass die URLs dem Code zugeordnet werden. Zum Beispiel in einem Rahmen sehen Sie oft Folgendes:

Obwohl die alten CGI-Skripte normalerweise nicht so funktionieren, haben Sie eher etwas wie:

Um das Framework zu nutzen, müssen Sie möglicherweise alle URLs ändern. Ob Sie das tun können und wie Sie alte Links beibehalten, kann einen großen Teil Ihrer Entscheidung ausmachen.

Auch Frameworks bieten Unterstützung für eine Art von ORM (objektrelationalem Mapper), die die Datenbankaufrufe abstrahiert und Ihnen erlaubt, nur mit Objekten umzugehen. Für Catalyst ist dies normalerweise DBIx::Class . Sie sollten bewerten, wie hoch die Kosten dafür sind.

Sie werden wahrscheinlich feststellen, dass Sie eine komplette Neuschreibung durchführen wollen, mit dem alten Code als Referenzplattform. Dies kann viel weniger Arbeit sein, als Sie erwarten. Beginnen Sie jedoch mit ein paar Spielzeugseiten, um ein Gefühl dafür zu bekommen, für welches Framework / Orm / Template Sie sich entscheiden.