CGI Skript auf Command line ausführbar

[mzh]

Liebes Forum
Ich patche gerade ein CGI Skript zusammen. Gerne würde ich es ab und zu auch per Command Line ausführen. Gibt es einen Weg, auf der CL quasi den Apache zu "simulieren", dh. das gleiche Verhalten zu erreichen wie wenn das Skript im Browser starten würde, allerdings jetzt auf der CL? Hab mich umgesehen, allerdings scheint das nicht gerade so trivial zu sein, wie macht ihr das?

[lunar]

@mzh: Ist das nicht offensichtlich: Anwendungslogik abtrennen, und separate CGI- und CLI-Frontends implementieren?

[mzh]

@lunar: Ok. Konkret seh ich in diesem Punkt nicht durch. Angenommen, das CGI Skript nimmt ein paar Werte aus einer HTML Form entgegen und baut die als Argumente in irgend eine Funktion ein, wie kann ich im Skript feststellen lassen, ob der Aufruf über Apache erfolgt ist, oder über die CL? Im CL-Fall werden dann ja keine Werte übermittelt (also FieldStorage ist "leer"), dh. für diesen Fall müssten ein paar Default Werte bereit stehen. Oder kann man sagen, wenn FieldStorage "leer" ist, dann ist wohl der Aufruf über die CL erfolgt?

[BlackJack]

@mzh: Wenn das CGI-Skript aufgerufen wurde musst Du gar nichts erkennen. Es wurde ja das CGI-Skript aufgerufen und nicht das Kommandozeilen-Skript. Schlag mal die Worte *trennen* und *separat* nach.

Wenn Du beide Frontends unbedingt vermischen willst, würde ich das so schreiben, dass es sich normalerweise als CGI-Skript verhält und eine Kommendozeilenoption besitzt, mit der man das Verhalten explizit auf Kommandozeilen-Schnittstelle umschalten kann.

[mzh]

@blackjack: hm, also "trennen" hat glaub irgendetwas mit "rennen" zu tun und "separat" ist vielleicht eine Kurzform für die gemeine "Sepa"-Ratte, kann das sein? Im Ernst, wie testet man also CGI Skripte am Besten?

[BlackJack]

@mzh: *Das* ist ja nun schon wieder eine ganz andere Frage. Die Logik, die ja unabhängig von CGI sein sollte, kann man zum Beispiel mit Unittests testen. Das Gesamtsystem aus Anwendersicht eigentlich eher in dem man Tests schreibt, die den Browser steuern. In beiden Fällen braucht man keine Kommandozeilen-Version des CGI-Skripts.

[mzh]

Kannst du mir zur skript-basierten Steuerung des Browsers ein Stichwort geben unter welchem ich mehr dazu finde?

[lunar]

@mzh: Selenium

[deets]

@Lunar: ich wuerde Selenium nicht empfehlen fuer den OP. Das lohnt sich nur, wenn man wirklich den Browser als ausfuehrende Umgebung braucht, fuer DOM/JS und Co. Braucht er ja gar nicht.

@mzh: am besten ist, du vergisst einfach mal das es CGI gibt. Sondern benutzt stattdessen WSGI, zB in Form von Bottle. Und dann benutzt du das exzellente Paket "webtest", um unit-tests zu schreiben, die deine WSGI-Anwendung testen.

Wenn es denn unbedingt CGI sein muss, weil du nicht mehr als 50 Cent im Monat fuer Hosting ausgeben magst, dann kannst du mittels flup auch noch CGI nach WSGI wandeln.

[mzh]

@deets: Ich bin dran mich in Django einzuarbeiten. Im Moment muss einfach etwas auf der Seite erscheinen (keine hohen Anforderungen an die Effizienz) und da ich nur CGI kenne (was einfach Python ist), muss ich für den Moment damit arbeiten.

[deets]

WSGI & Bottle sind einfacher als CGI.

[mzh]

WSGI & Bottle sind einfacher als CGI.

OK, also im Prinzip gehts darum, in einer HTML Form wird ein Parameter eingegeben, dann wird auf submit geklickt, dann startet eine Pythonanwendung auf dem Server und dann wird das Resultat in eine neue HTML Seite geschrieben, die an den Browser zurückgegeben wird. Dass hab ich jetzt mit CGI gemacht, weil ich so (mit dem Python CGI Modul) einfach an die Daten in der Form gekommen bin.
So was will ich machen, im Prinzip gehts mir nur darum, an die Daten aus der HTML Form ranzukommen. Wenn ich es richtig verstehe, dann sollte CGI *nur* für die Übertragung der Daten an den Server verwendet werden, die Berechnung überlässt man dem Framwork.

[deets]

Nicht so ganz verstanden. CGI & Framework behandeln denselben Teil - naemlich serverseitig die HTTP-Handhabung zu machen, und das Ergebnis in Form von HTML aufzuarbeiten.

Deinen eigentlichen funktionalen Kern solltest du so programmieren, dass er zB als eigenes Modul daherkommt, und dann einfach getestet werden kann, als Kommandozeile oder per unittest oder was auch immer.

Mit bottle musst du dich halt um die entzifferung des HTTP-Requests nicht kuemmern, sondern bekommst Parameter bequem als Dictionary. Und genauso ist das rendern des Ergebnis dank templating und abstrahiertem Response-Objekt auch einfacher.

Aber der Schluessel liegt in der sauberen Separation von HTTP-Frontend - egal ob CGI oder WSGI/bottle - und deiner eigentlichen Logik. Da du nicht in's detail gehst, was da eigentlich passiert, kann man da auch nicht mehr zu sagen.

[jerch]

Was ist den "das Framework"?

Wenn die Abarbeitung der Frameworkänderungen nicht in einen Request/Response-Zyklus passen (bzw. nicht serialisierbar zwischen verschiedenen Requests sind), geht das nicht innerhalb von CGI oder WSGI.
Ohne weitere Details lässt sich hierzu allerdings nichts sagen.

Wenn ich es richtig verstehe, dann sollte CGI *nur* für die Übertragung der Daten an den Server verwendet werden, die Berechnung überlässt man dem Framwork.

Nein, CGI ist nichts als eine Übereinkunft, wie Anwendungen an HTTP-Requests gebunden werden (selbiges gilt für WSGI).