Nachtrag: Ich habe irgendwie die zahlreichen Antworten auf Deine Fragen nicht gesehen, sonst hätte ich jetzt nicht so viel Kram getextet. Für mich sah es aus, als hättest Du noch keine Antwort bekommen. Vergiss es einfach :-)

Hallo plinepa,

CGI ist generell mal nur eine Schnittstelle (das I steht für Interface) und hat nichts mit der Programmiersprache zu tun, mit der der Webserver kommuniziert. Apache kann mit Perl, PHP, Python, C und vielen anderen Programmiersprache CGI sprechen.
Gemeint ist hier mit CGI ein Modul, das dir das Leben im Webumfeld ein gutes Stück leichter macht: http://search.cpan.org/~markstos/CGI.pm-3.63/lib/C...
Du kannst den Header für ein HTML Dokument zu Fuß ausgeben (print "Content-type: text/html\n\n";) oder von CGI ausgeben lassen (print $cgi->header(-type => 'text/html');). Beim Header hast Du noch keinen ernsthaften Vorteil. Wenn es aber z.B. darum geht, GET/POST Parameter auszulesen, kommst Du an CGI.pm eigentlich nicht vorbei, weil es da so viele Besonderheiten bzgl. Query/POST, Encoding, Escaping usw. zu beachten gibt. In CGI liest Du den Parameter 'test' ganz einfach per my $parameter = $cgi->param('test');. Ohne CGI.pm musst dafür ausgiebig Query String parsen bzw. POST Content verarbeiten, sowie entscheiden, was von beiden Du nun tust usw. Zu Fuß also eine klare Empfehlung für CGI.pm
Ich würde mich aber darauf beschränken, die Schnittstellen Funktionen von CGI.pm zu nutzen. Solche Sachen wie $cgi->h3('Meine Ueberschrift'); haben für mich im Regelfall nichts im Perl Code zu suchen.

Wie Du schon festgestellt hast, sieht der Quelltext eine Perl Anwendung anders aus, als der einer PHP Anwendung. Vergleichbar werden sie erst, wenn Du Deine PHP Anwendung mit <?php beginnst und diesen PHP Block erst am Ende der Datei wieder schließt. Also keinen Inline Quelltext schreibst. Man könnte mit HERE Dokumenten usw. auch in Perl was vergleichbares machen, aber das ist kein guter Stil. HTML Quelltext gehört in Templates.

Ein Fingerzeig für eine Template Engine ist das Template Toolkit. Sehr leistungsfähig und gut gewartet. Ich hatte schon ein paar andere in Gebrauch und bin letztlich dort hängen geblieben:
http://search.cpan.org/~abw/Template-Toolkit-2.25/...

Bzgl. Frameworks: Ich denke, dass es sinnvoll ist, erstmal zu Fuß mit CGI.pm die ersten Schritte zu machen. Frameworks sind leistungsfähig und haben viele Vorteile - brauchen aber auch viel Einarbeitung (einige mehr, andere weniger). Ich bin Catalyst Anhänger, aber frage zehn Leute und Du bekommst zehn Meinungen. Ich behaupte, dass Catalyst aktuell am verbreitetsten ist, aber es ist nicht für seinen Schnellstart bei Neulingen bekannt.

Verbreitet sind momentan vier Möglichkeiten, sein Perl Skript unter Apache laufen zu lassen:
- Als "normales" CGI: Wie Du richtig vermutest, wird es bei jedem Aufruf neu interpretiert und kompiliert, daher hat es immer einen gewissen Anlaufhuster. Bei einer einfachen privaten Webseite wirst Du davon aber nichts merken und auch keine Performance Problem bekommen.
- mod_perl/mod_perl2: Damit habe ich beruflich längere Zeit gearbeitet. Es hat die gesamten Bibliotheken im Speicher und läuft bei häufigen Aufrufen schneller als ein normales CGI. Ich habe aber auch einige Schwierigkeiten bei mod_perl festgestellt. Erstens sind die Einstellungen im Apache dafür sehr komplex und es passiert schnell, dass ein mod_perl Skript den ganzen Webserver abschmieren lässt. Bei vielen Daten und ungünstiger Programmierung ist nämlich sehr schnell der Arbeitsspeicher voll. Außerdem lassen sich Skripte unter mod_perl bescheiden debuggen. Die Kopplung zwischen mod_perl und Apache ist extrem eng. Meines Wissens ist es nicht möglich, mehrere Anwendungen unter unterschiedlichen Benutzern auszuführen. Deshalb findest Du auch kaum Webhoster, die mod_perl Support anbieten.
- mod_fastcgi: Verfolgt einen ähnlichen Ansatz wie mod_perl, die Kopplung zwischen Apache und Perl ist aber deutlich laxer. Man kann jede Seite unter einem anderen Benutzer laufen lassen und die Anwendungen können sich normalerweise nicht gegenseitig beeinflussen. Einmal komplierter Quelltext bleibt ebenfalls im Speicher und veringert die Ladezeit für alle zukünftigen Aufrufe. Der Nachteil ist, dass mod_fastcgi meines Wissens zwar kostenlos nutzbar ist, aber kein Opensource ist bzw. keiner gängigen Opensource Lizenz unterliegt. Deshalb muss man z.B. bei Debian die non-free Paketquellen aktivieren.
- mod_fcgid: Ist (bzw. soll sein) ein binärkompatibler Nachbau von mod_fastcgi, der eine gängigen Opensource Lizenz unterliegt. Teilweise wurde noch von Inkompatibilitäten berichtet, aber ich habe noch keine festgestellt. Mittlerweile ist mod_fcgid mein bevorzugter Weg, Perl auf Apache laufen zu lassen. Auch mit Catalyst habe ich noch keine Probleme festgestellt.

Die beiden letzten arbeiten standardmäßig ähnlich zum "normalen" CGI. Bzw. wirst Du vermutlich ohnehin eine der beiden Möglichkeiten nutzen ohne es zu wissen. Wenn Du die Vorteile des "Im-Speicher-haltens" nutzen willst, musst Du auch entsprechende Programme schreiben.


Noch ein kurzes Wort zu Frameworks und diesen vier Varianten: Ich weiß nicht, wie es bei Dancer usw. ist, aber Catalyst arbeitet hervorragend mit mod_fcgid zusammen. Es ist deutlich spürbar, dass bei größeren Anwendungen der erste Start nach Webserver-Restart lange braucht (mehrere Sekunden). Das liegt an der umfangreichen Bibliothek, die kompliliert wird. Alle weiteren Aufrufe gehen dafür aber sehr flott.

Viele Grüße
Martin
Last edited: 2013-09-23 14:54:22 +0200 (CEST)