CGI – ein veraltetes Konzept?
Diese Frage stellt sich einem sehr schnell, wenn man schaut, wie dynamische
Webinhalte heutzutage erzeugt werden: AJAX hier, PHP dort, jQuery da – sowie
eine ganze Reihe anderer Ansätze, um Inhalte direkt beim Aufruf einer Seite
zusammenzustellen und anzuzeigen. Manche von ihnen funktionieren serverseitig
(siehe PHP), während wiederum andere auf die Fähigkeiten des Browsers
angewiesen sind (wie AJAX oder jQuery).
Dabei geht PHP sehr wohl in Richtung CGI, nur daß es sich bei PHP-Dateien um
einen Hybrid aus regulärem HTML-Code und Skriptbereichen handelt, wobei
letztere vom Webserver als solche erkannt und ausgeführt werden. Das Ergebnis
wird dann zusammen mit den restlichen HTML-Daten an genau der Stelle
ausgegeben, an der der Skriptbereich notiert ist.
Im Falle von CGI läuft es jedoch etwas anders ab als im Fall von PHP: Wird eine
Anforderung an den Webserver gestellt, die auf ein CGI-Skript oder -Programm
verweist, so wird dieses vom Webserver gestartet. Etwaige zu übergebene Daten
werden dabei im Falle von URL-Parametern als Umgebungsvariable übergeben, oder
wenn POST-Daten weitergereicht werden, so landen diese auf der Standardeingabe
des CGI-Programms, welches die so übergebenen Daten verarbeitet und das daraus
ermittelte Ergebnis auf seiner Standardausgabe ausgibt. Dieses wiederum wird
vom Webserver entgegengenommen und an den Aufrufer weitergeleitet.
Dadurch wird der Webserver entlastet, so daß er sich ausschließlich mit dem
Ausliefern angeforderter Daten befassen muß – etwaige Auswertungen laufen in
einem komplett eigenständigen Prozeß ab.
Aber warum gerade CGI und nicht PHP?
Im Gegensatz zu CGI hat PHP einen entscheidenden Haken: Man ist hier auf eine
bestimmte Skriptsprache festgelegt, wohingegen diese Beschränkung für CGI nicht
besteht. In letzterem Fall können Sie jedes x-beliebige Programm, das Daten auf
der Standardeingabe erwartet und seine Ergebnisse auf der Standardausgabe
bereitstellt, verwenden, so diese auf die CGI-Schnittstelle ausgelegt sind oder
sich an diese Gegebenheit anpassen können. Das gestattet es, auch Shellskripte,
Skripte in einer beliebigen Skriptsprache (Perl, Python, Tcl, etc.) oder gar
ausgewachsene Programme aufzurufen. Ihnen stehen hier nahezu alle Möglichkeiten
offen.
Zudem sind Sie beim Einsatz von CGI vollkommen frei in dem, was Sie an den
Aufrufer zurückliefern: Sie können diesem sogar mitteilen, welche Art von Daten
Sie in welcher Form zurückliefern!
Wie Perl ins Spiel kommt
Perl zeichnet sich, was die Programmierung betrifft, durch eine
außerordentliche Flexibilität aus, die es einem ermöglicht, nahezu alles damit
anzustellen. So können Sie in einer Variablen alle möglichen und unmöglichen
Daten unterbringen, ohne sich um deren Struktur einen Kopf machen zu müssen
(einzig die Unterscheidung zwischen Skalaren – also Einzeldaten – Listen und
Hashes ist hier erforderlich), den Rest erledigt Perl für Sie. Und auch wenn
Sie Daten von einer Form in eine andere transformieren müssen, so müssen Sie
keine Energie darauf verschwenden, da dies intern von Perl vorgenommen wird.
Zudem lassen sich Perlskripte modular aufbauen, so daß Sie Funktionen, die Sie
in mehreren Skripten einsetzen wollen, einfach in eine weitere Datei auslagern,
die Sie einfach in ihre Skripte einbinden. Somit vermeiden Sie, daß Sie
einunddenselben Code an verschiedenen Stellen notieren müssen, was die Wartung
Ihres Codes deutlich vereinfacht. Ergeben sich Probleme, so müssen Sie
lediglich an einer Stelle etwas verändern; die Änderungen werden dann an allen
Stellen, an denen Sie das betroffene Modul eingebunden haben, übernommen.
Darüber hinaus gestaltet der Programmierstil von Perl, der locker an den von
C angelehnt ist, die Arbeit ebenfalls einfacher und läßt Ihnen zugleich mehr
Freiheiten. Dies vereinfacht die Arbeit zusätzlich, und anstatt sich um die
interne Darstellung von Daten kümmern zu müssen – nebst der ggf. notwendigen
Umwandlungen – können Sie sie nahezu nach Belieben einsetzen.