Hallo,
ich habe Python vor einigen Monaten entdeckt und einige Skripte und kleine Programme damit geschrieben. Meine Webseiten habe ich bisher ausschließlich mit PHP erstellt. Für mich entsprechen die Dateien auf der Platte den URLs im Apache (von mod_rewrite mal abgesehen) und bei jedem Aufruf einer Webseite im Browser wird das PHP Skript von Apache (oder entsprechendem Modul) geladen, interpretiert und alle Ausgaben an den Browser gegeben, dabei noch entsprechende Header hinzugetan.
Jetzt würde ich gerne Python im Web verwenden. Allerdings scheint es ja nicht ganz so wie bei PHP zu sein. Bei Flask (und Django, wahrscheinlich bei allen) hat man einen kleinen Webserver mit dem sein "Webapp" (was auch immer das ist) starten kann und dann läuft es mit einem eigenen Server. Das verstehe ich soweit auch noch ganz gut, schließlich habe ich in der Schule mal einen Chatserver in Delphi gebaut.
Was ich jetzt allerdings überhaupt nicht verstehe ist, wie ich meine "Webapp", in dem ich wohl mit Hilfe dieser "Routen" irgendwie gesagt habe, was passieren soll, nun auf den Webspace bei Strato bekomme. Da ich kein SSH habe, kann ich schlecht dort den Flask Server starten, außerdem wäre das dann ja nicht Port 80.
Wie schaffe ich es, dass ich bei Strato das Beispiel auf http://flask.pocoo.org/ zum Laufen bekomme?
Wie muss ich mir dieses "Webapp" vorstellen? Als "Server", der die ganze Zeit läuft, einen Seitenaufruf mit einer Funktion bearbeitet?
Grüße,
devek
Webprogrammierung mit Py für einen PHP-Benutzer
@devek: Die eigenen Webserver in den meisten Rahmenwerken sind hauptsächlich zum Entwickeln gedacht. Wenn man die Anwendung ”deploy”t, dann in der Regel beim Apache mit `mod_wsgi` oder über eine FastCGI-Schnittstelle. Dazu muss man aber bis zu einem gewissen Grad den Webserver konfigurieren können und dürfen.
Ich gehe davon aus, dass ich in meinem Strato Paket recht wenig konfiguieren darf. Was müsste ich denn eigentlich konfigurieren? PHP klappt ja auch "einfach so"?
Sry für die PHP Sichtweise, aber das ist leider meine einzige Sichtweise auf das ganze Thema :-/
Sry für die PHP Sichtweise, aber das ist leider meine einzige Sichtweise auf das ganze Thema :-/
@devek: PHP klappt einfach so weil es eben schon für Dich konfiguriert ist, und weil das 1:1 abbilden von URL auf PHP-Datei so simpel ist, dass man auch für einzelne Webanwendungen nicht noch extra etwas einstellen muss.
Ich sitze an ähnlichen "Problemen".
Das mit den Routen ist in der Tat gewöhnungsbedürftig. Auch ein Webseitenlayout ist meiner Meinung nach schwerer zu erstellen, als in PHP, sofern man nicht auf ein Framework und dessen "Template-Engine" zurückgreift (und die wahrscheinlich dann auch ein paar "Designvorgaben" haben, wie bei PHP bei vielen CMS, so dass ein komplett freies Layout eventuell nicht wie gewünscht machbar ist).
Das mit dem WSGI scheint auch nicht so ganz einfach zu sein. Und den Apache für WSGI zu konfigurieren, auch nicht.
Ich will jetzt erst mal python für das "innenleben" benutzen. Ein und Ausgabe bzw Template/Layout aber weiterhin über PHP. Ich will also Python und PHP miteinander "Verkuppeln".
Das mit den Routen ist in der Tat gewöhnungsbedürftig. Auch ein Webseitenlayout ist meiner Meinung nach schwerer zu erstellen, als in PHP, sofern man nicht auf ein Framework und dessen "Template-Engine" zurückgreift (und die wahrscheinlich dann auch ein paar "Designvorgaben" haben, wie bei PHP bei vielen CMS, so dass ein komplett freies Layout eventuell nicht wie gewünscht machbar ist).
Das mit dem WSGI scheint auch nicht so ganz einfach zu sein. Und den Apache für WSGI zu konfigurieren, auch nicht.
Ich will jetzt erst mal python für das "innenleben" benutzen. Ein und Ausgabe bzw Template/Layout aber weiterhin über PHP. Ich will also Python und PHP miteinander "Verkuppeln".
Die Frameworks folgen dem Prinzip die einzelnen Elemente wie Templates und das Model zu separieren. Das hat sich als sehr sinnvoll erwiesen. Was du vielleicht vermisst ist die `quick and dirty`-Lösung.
Wenn du Freiheit haben willst, kannst du dir Werkzeug anschauen (was du aber sicherlich nicht willst).
Leider haben die meisten Hoster keinen echten Pythonsupport. Die, die das haben kosten etwas mehr. pyrox.eu ist hier recht beliebt.
Die Konfiguration von mod_wsgi ist relativ einfach, wenn du den Schritten folgst: http://flask.pocoo.org/docs/deploying/mod_wsgi/
Wenn du Freiheit haben willst, kannst du dir Werkzeug anschauen (was du aber sicherlich nicht willst).
Leider haben die meisten Hoster keinen echten Pythonsupport. Die, die das haben kosten etwas mehr. pyrox.eu ist hier recht beliebt.
Die Konfiguration von mod_wsgi ist relativ einfach, wenn du den Schritten folgst: http://flask.pocoo.org/docs/deploying/mod_wsgi/
[url=http://wiki.python-forum.de/PEP%208%20%28%C3%9Cbersetzung%29]PEP 8[/url] - Quak!
[url=http://tutorial.pocoo.org/index.html]Tutorial in Deutsch[/url]
[url=http://tutorial.pocoo.org/index.html]Tutorial in Deutsch[/url]
- Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Hast Du Dir jinja2 mal länger als eine Minute angeguckt? Sagen wir mal so 10 Minuten? Bei Flask ist es sogar schon entsprechend konfiguriert, so dass man sofort loslegen kann.Coder hat geschrieben:Auch ein Webseitenlayout ist meiner Meinung nach schwerer zu erstellen, als in PHP, sofern man nicht auf ein Framework und dessen "Template-Engine" zurückgreift (und die wahrscheinlich dann auch ein paar "Designvorgaben" haben, wie bei PHP bei vielen CMS, so dass ein komplett freies Layout eventuell nicht wie gewünscht machbar ist).
Auch wenn ich hier Flask exemplarisch nenne, gilt das für quasi jedes aktuelle Template-System (Mako, Genshi, Djangos internes, ...). Ich sehe da nirgends Einschränkungen hinsichtlich des Layouts. Wieso auch; diese Engines sind ja nicht auf HTML limitiert.
Probleme treten doch vor allem dann auf, wenn man eben alles selber machen will und HTML zu Fuß selber rendert. Daher gibt es Frameworks, die einem ausgereifte Konzepte zur Verfügung stellen.
Natürlich muss man sich dann beim Hosting (zunächst) ein wenig mehr Mühe machen. Die Entwicklung hingegen ist ja sogar deutlich komfortabler, weil man eben kein aufwendiges Deployment (und sei es nur das Kopieren von Dateien mit root-Rechten) hat.
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert
In der Deployment Seite von Flask steht, dass man eine .wsgi Datei anlegen und noch etwas in die Apache Konfigurationsdatei schreiben soll (letzteres kann ich sicher nicht machen).
Bei Strato steht nur was von cgi-bin und Perl, und in einem Satz, dass halt Python auch unterstützt wird.
Ich habe gerade ein Skript mit der Zeile in /cgi-bin/hello.py hochgeladen, doch vom Server kam dann nur ein Fehler 500.
Bei Strato steht nur was von cgi-bin und Perl, und in einem Satz, dass halt Python auch unterstützt wird.
Ich habe gerade ein Skript mit der Zeile
Code: Alles auswählen
print "Hello, World"
@devek: Das ist ja auch ein fehlerhaftes CGI-Skript. Im Serverlog steht wahrscheinlich etwas von ”premature end of headers”. Wenn Du schon CGI von Hand schreibst, musst Du Dich auch an das Protokoll halten.
Ausserdem kann es sein, dass die Endung `.py` nicht unterstützt wird und der Webserver grundsätzlich `.cgi` haben möchte. *Spätestens* dann braucht man in dem Skript auch eine ”she bang” Zeile, damit klar ist womit das Skript ausgeführt werden soll. Die braucht man eigentlich auch so schon, denn dass die Dateiendung das regelt, ist unter Unix/Linux nicht üblich.
Ausserdem kann es sein, dass die Endung `.py` nicht unterstützt wird und der Webserver grundsätzlich `.cgi` haben möchte. *Spätestens* dann braucht man in dem Skript auch eine ”she bang” Zeile, damit klar ist womit das Skript ausgeführt werden soll. Die braucht man eigentlich auch so schon, denn dass die Dateiendung das regelt, ist unter Unix/Linux nicht üblich.
Shebang war drin, den hatte ich nur nicht zitiert. Als Endung habe ich auch noch .cgi ausgetestet und das ganze dann auch mit perl gestartet (print ist ja gleicht) und mit Endung .pl, gleicher Fehler. Wird dann wohl am Skript selbst liegen.
Bei SelfHTML ist ein Beispielskript in Perl, aber das sieht auch nicht wirklich komplizierter aus.
Irgendwie habe ich das Gefühl, dass ich noch irgendwas essenzielles nicht verstanden habe …
Bei SelfHTML ist ein Beispielskript in Perl, aber das sieht auch nicht wirklich komplizierter aus.
Irgendwie habe ich das Gefühl, dass ich noch irgendwas essenzielles nicht verstanden habe …
@devek: Ein CGI-Skript muss eine gültige HTTP-Antwort liefern und da gehören nun mal die Header dazu. Das sollte einem aber auch jedes CGI-Tutorial erklären. Ausserdem steht im Log vom Webserver in der Regel was schief gelaufen ist. Da hinein zu schauen wenn eine Fehlermeldung ausgeliefert wird, sollte die erste Reaktion sein, bevor man einfach wild weiter probiert woran es denn gelegen haben könnte.
Die Datei sollte ausserdem ausführbar sein. Also das ”executable bit” sollte gesetzt sein.
Die Datei sollte ausserdem ausführbar sein. Also das ”executable bit” sollte gesetzt sein.
@BJ: Ha! jetzt funktioniert es mit Perl:
/cgi-bin/hello.pl
Bei einem ähnlichen Python Skript funktioniert es allerdings nicht (weiterhin 500), weder mit .py oder .cgi als Endung.
Fehlermeldungen sehe ich nicht, an das Log komme ich anscheinend nicht dran.
/cgi-bin/hello.pl
Code: Alles auswählen
#!/usr/bin/perl
print "Content-type: text/html\n\n";
print "Hello, World"
Fehlermeldungen sehe ich nicht, an das Log komme ich anscheinend nicht dran.
- Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Wie sieht denn das "ähnliche" Script aus?devek hat geschrieben: Bei einem ähnlichen Python Skript funktioniert es allerdings nicht (weiterhin 500), weder mit .py oder .cgi als Endung.
Das ist natürlich schlecht.Fehlermeldungen sehe ich nicht, an das Log komme ich anscheinend nicht dran.
Generell scheinst auch Du den Deploymentprozess vor die eigentliche Entwicklung zu verlagern. Willst Du nicht lieber erst einmal lokal mit Flask, Django oder Bottle etwas entwickeln und Dir dann ggf. einen Hoster suchen, der WSGI direkt unterstützt?
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
assert encoding_kapiert
Das entsprechende Pythonskript sah so aus:
Webdesign ist letztlich nur ein Hobby, außerdem kann ich bisher alles, was ich brauche, mit PHP erledigen. Python wollte ich einfach mal ausprobieren, aber dafür jetzt kein Geld ausgeben. Eigentlich wollte ich nur mal schauen, was ich denn eigentlich damit machen kann, aber irgendwie scheint das nicht so einfach. Daher habe ich Deployment vor Development gesetzt, um am Ende nicht mit jede Menge Wissen da zu stehen, was mir allerdings wenig nützt.
Code: Alles auswählen
#!/usr/bin/python
print "Content-type: text/html"
print "Hello, World"
@devek: Oh mann. Vergleich doch mal die Ausgabe der beiden Skripte. Und dann beschäftige Dich doch mal etwas näher mit CGI. Der Ausgabe muss eine bestimmte Form haben. Die sollte man nicht durch ausprobieren heraus bekommen, sondern durch lesen von Dokumentation.
Das gibt nun nicht das gleiche aus wie das Perl-Skript. Die Zeilenumbrüche fehlen.devek hat geschrieben:Code: Alles auswählen
#!/usr/bin/python print "Content-type: text/html" print "Hello, World"
- daemonTutorials
- User
- Beiträge: 171
- Registriert: Sonntag 6. Februar 2011, 12:06
- Kontaktdaten:
Ähm, du trennst Header nicht von Content!
Du musst zwischen Header und Content eine Zeile "drucken" oder ausgeben!
Dies sollte funktionieren!
Du musst zwischen Header und Content eine Zeile "drucken" oder ausgeben!
Code: Alles auswählen
#!/usr/bin/python
#!-*- coding: utf-8 -*-
# Du solltest das Charset setzen, um evtl. Zeichenfehler auszumerzen!
print "Content-Type: text/html\n"
print ""
print "Hello World!"
LG Maik
@daemonTutorials
Also entweder "\n", oder extra prints. So wie du das schreibst ist es falsch. Es wird einem nicht um die Ohren fliegen, weil auch ein newline Teil des plain-text ist, aber es suggeriert man braeuchte *3* newlines! Und das stimmt ja schlicht nicht.
Also entweder "\n", oder extra prints. So wie du das schreibst ist es falsch. Es wird einem nicht um die Ohren fliegen, weil auch ein newline Teil des plain-text ist, aber es suggeriert man braeuchte *3* newlines! Und das stimmt ja schlicht nicht.
- daemonTutorials
- User
- Beiträge: 171
- Registriert: Sonntag 6. Februar 2011, 12:06
- Kontaktdaten:
Danke an die lieben Herren vom Galileo Computing Python-Buch, die das so schön für mich erklärt haben!
Tja, da habe ich ja wieder was neues gelernt. Tut mir leid!
Tja, da habe ich ja wieder was neues gelernt. Tut mir leid!
LG Maik