Hallo Stefan,
- kein -w
- kein use strict / kein my
- kein use CGI (Querystrings werden mit veraltetem Code geparsed)
- teilweise keine Überprüfung von Rückgabewerten (flock, close)
- keine Einhaltung an gültige Konventionen
Auch wenn strict zum guten Ton gehoert - aber wenn es wirklich soooo verpflichtend waere, warum ist es dann nicht laengst Default beim Perl-Interpreter?
Da perl -e auch Perlcode von der Kommandozeile verarbeitet, wäre es sehr umständlich alle Variablen zu deklarieren, bzw. bei Verwendung kritischer Konstrukte 'strict' teilweise wieder abzuschalten (z.B. um symbolische Referenzen zu verwenden).
Außerdem würden die meisten der richtig coolen JAPHs nicht mehr funktionieren ;-))
Und "use CGI" ist auch noch kein Gesetz, das der liebe Gott gemacht hat, es ist nur eine der beliebtesten ewigen Stammtisch-Wiederholungen in den Newsgroups. Kein Zweifel - das CGI-Modul ist sinnvoll. Aber fuer ein Script, das nur ein einziges Formularfeld auszuwerten hat, moeglicherweise nicht. Denn jedes Modul-Laden erzeugt ja auch wieder Serverlast.
Deswegen wird vom 'perlmaker' auch kein -w verwendet, da jeder Eintrag im 'error_log' (und davon kämen sicherlich etliche) ebenfalls den Server belastet, wie ich am eigenen Leib schon feststellen musste :-)
Wenn es nur um die Ladezeit geht, kann man auch CGI::Lite verwenden, daß mit ca 27K (ein Großteil ist Dokumentation) doch angenehm lite ist :-). Denn spätestens wenn es sich bei dem einzelnen Forumularfeld um ein filefeld handelt, wird der GET&POST-code versagen. Genauso bei multipleselect, oder bei mehreren Checkboxen mit gleichem 'name'. Und wo wird dann mit 'perldoc CGI' auf welche Fragen geantwortet? *vbg*
Ansonsten stimme ich dir durchaus zu. Die "Bausteine", die das Tool liefert, lassen sich wahrscheinlich noch verbessern.
Die Bausteine sind imho nicht nur verbesserungsdürftig, sondern auch z.T. schlichtweg invalides Perl!
Gruß AlexBausW