Seite 1 von 3

Verfasst: Donnerstag 2. Februar 2006, 18:06
von N317V
Also ich muss aber sagen, dass ich vor Webprogrammierung mit Python auch noch etwas zurückschrecke. Das geht wohl nicht nur mir so, wenn man mal guckt, dass z.B. sogar dieses Forum mit PHP läuft. Es gibt da wohl eine lange Reihe an Möglichkeiten; viele Schlagworte wie mod_python, ZOPE, WSGI etc. sind hier ja schon gefallen. Nur: meist erscheint das alles ziemlich kompliziert aufzusetzten und ist teilweise vollkommener Overkill, oft auch einfach schlecht dokumentiert. Das PEP zu WSGI ist zum Beispiel recht informativ, aber ich kann immernoch nicht wirklich sagen, was ich tun muss, um es zu nutzen. Es scheint wohl nicht automatisch bei Python dabei zu sein und ist dementsprechend auch in der Python-Doku nicht zu finden (Version 2.4). Bis ich die ZOPE-Doku auch nur annähernd durchgearbeitet hab, hätte ich das bisschen, das ich brauche schon längst "zu Fuß" programmiert. Für größere Projekte sicher geil, aber für den Einstieg einfach viel zu gewaltig. Um das gleich vorweg zu nehmen: auch das ZOPE-Tutorial ist bei mir schon bei der Installation durchgefallen, weil viel zu viele Dinge einfach nicht so funktionieren, wie dort beschrieben und ich dafür dann wieder jede Menge anderer Doku durchforsten muss um das Ding überhaupt mal anständig auf die Platte zu kriegen. Das sind jetzt nur zwei Beispiele, aber ich hab mich noch mit mod_python, Twisted, Colubrid, Plone und CherryPy beschäftigt. Die Probleme scheinen mir über gleich: entweder zu überladen oder zu unausgereift oder einfach mangelhaft dokumentiert. Sich da einen Überblick zu verschaffen ist schon reichlich mühselig, aber ich werd wohl die Liste auf pythonwiki.de noch weiter durcharbeiten. :?

just my 2 cent

Verfasst: Donnerstag 2. Februar 2006, 19:50
von mitsuhiko
N317V hat geschrieben:Also ich muss aber sagen, dass ich vor Webprogrammierung mit Python auch noch etwas zurückschrecke. Das geht wohl nicht nur mir so, wenn man mal guckt, dass z.B. sogar dieses Forum mit PHP läuft.
Weil Pocoo noch etwas dauert.
Es gibt da wohl eine lange Reihe an Möglichkeiten; viele Schlagworte wie mod_python, ZOPE, WSGI etc. sind hier ja schon gefallen. Nur: meist erscheint das alles ziemlich kompliziert aufzusetzten und ist teilweise vollkommener Overkill, oft auch einfach schlecht dokumentiert. Das PEP zu WSGI ist zum Beispiel recht informativ, aber ich kann immernoch nicht wirklich sagen, was ich tun muss, um es zu nutzen.
Du musst es gar nicht nutzen. Das ist nur für die Framework Entwickler interessant. Du brauchst nur noch einen netten Aufsatz dazu suchen. Momentan sind die folgenden Frameworks WSGI kompatibel: django, turbogears (eingeschränkt, cherrypy ist leider etwas kaputt), web.py. Als request handler (also dem einfachsten vom einfachsten) hätten wir da noch Colubrid.
Es scheint wohl nicht automatisch bei Python dabei zu sein und ist dementsprechend auch in der Python-Doku nicht zu finden (Version 2.4).
WSGI ist ein Standard. Die dbapi ist ja auch nicht in python dabei...
Bis ich die ZOPE-Doku auch nur annähernd durchgearbeitet hab, hätte ich das bisschen, das ich brauche schon längst "zu Fuß" programmiert. Für größere Projekte sicher geil, aber für den Einstieg einfach viel zu gewaltig.
Und für große zu langsam. ZOPE2 hat atm leider so seine Probleme. Nicht zuletzt wegen des etwas hirnverbrannten programmierens über die Weboberfläche. Habe aber gehört, dass ZOPE3 da alles richtig machen will.
Um das gleich vorweg zu nehmen: auch das ZOPE-Tutorial ist bei mir schon bei der Installation durchgefallen, weil viel zu viele Dinge einfach nicht so funktionieren, wie dort beschrieben und ich dafür dann wieder jede Menge anderer Doku durchforsten muss um das Ding überhaupt mal anständig auf die Platte zu kriegen.
Jep. Die doku ist für die Tonne.
Das sind jetzt nur zwei Beispiele, aber ich hab mich noch mit mod_python, Twisted, Colubrid, Plone und CherryPy beschäftigt. Die Probleme scheinen mir über gleich: entweder zu überladen oder zu unausgereift oder einfach mangelhaft dokumentiert.
mod_python is ein Interface, das ohne einem Aufsatz zu verwenden ist nicht nur dumm, sondern auch verrückt. Twisted ist viel mehr als ein Framework. Colubrid ist sehr gut dokumentiert, wenn was fehlt bitte sagen, aber meines Wissens nach ist alles in der Doku. Plone ist CMS für ZOPE und kein Framework, CherryPy ist ein etwas verkorkster Untersatz für subway und turbogears, aber gleichzeitig auch ein Frameworkansatz oder Application server. Je nachdem wie man es nimmt.
Sich da einen Überblick zu verschaffen ist schon reichlich mühselig, aber ich werd wohl die Liste auf pythonwiki.de noch weiter durcharbeiten. :?
Und wieder einer, der es falsch verstanden hat. Ich kann ja nicht sagen, dass es leicht zu kapieren ist, ich sollte da vielleicht eine Doku schreiben...

Verfasst: Donnerstag 2. Februar 2006, 23:09
von BlackJack
Ich denke wenn man es für den Anfang einfach haben will, so ähnlich wie PHP, dann sollte man mit CGI anfangen. Python lässt sich wegen der Syntax (Einrückung bestimmt Programmstruktur) nicht so einfach in HTML einbetten, deshalb sollte man ein Templating-System wie kid, SimpleTAL oder CheetahTemplate nehmen. Damit kann man Programm und Präsentation recht sauber trennen ohne sich in "Megaframeworks" einarbeiten zu müssen.

Ich persönlich finde `kid` ganz nett. Von der Homepage:
Kid is a simple template language for XML based vocabularies written in Python. It was spawned as a result of a kinky love triangle between XSLT, TAL, and PHP. We believe many of the best features of these languages live on in Kid with much of the limitations and complexity stamped out

Verfasst: Freitag 3. Februar 2006, 04:43
von mitsuhiko
BlackJack hat geschrieben:Ich denke wenn man es für den Anfang einfach haben will, so ähnlich wie PHP, dann sollte man mit CGI anfangen.
Sollte man nicht. Für eine CGI Anwendung muss man in der Regel viel nervtötendes erledigen. Beispielsweise multipart requests parsen... Da würde ich mir lieber Colubrid oder web.py ansehen. Die haben keine große Einarbeitungszeit.
Python lässt sich wegen der Syntax (Einrückung bestimmt Programmstruktur) nicht so einfach in HTML einbetten,...
Ney. Das stimmt so nicht. Python lässt sich genauso gut in HTML Code einbetten wie PHP auch. Beispiele dafür sind PSP, Cheetah, Spyce und andere.
deshalb sollte man ein Templating-System wie kid, SimpleTAL oder CheetahTemplate nehmen. Damit kann man Programm und Präsentation recht sauber trennen ohne sich in "Megaframeworks" einarbeiten zu müssen.
Da gibt es aber noch einige andere [wiki]Template Engines[/wiki] :wink:

Und wenn du meinst, dass du dich in plain CGI einarbeiten willst - arbeite dich lieber in plain WSGI ein. Ca gleich nervtötend, ist aber ein besserer Weg. Und ansonsten, wie gesagt, Colubrid ist ein einfacher Weg.

Und da das generell immer nach Werbung aussieht, schreib ich jetzt eine WIkiseite zu dem Thema: [wiki]Python und die Webentwicklung[/wiki]

Verfasst: Freitag 3. Februar 2006, 10:46
von BlackJack
blackbird hat geschrieben:
BlackJack hat geschrieben:Ich denke wenn man es für den Anfang einfach haben will, so ähnlich wie PHP, dann sollte man mit CGI anfangen.
Sollte man nicht.
Sollte man doch. Was bleibt denn anderes übrig wenn man partout keine Webframeworks verwenden möchte? Diese Anforderung stammt ja nicht von mir.
Für eine CGI Anwendung muss man in der Regel viel nervtötendes erledigen. Beispielsweise multipart requests parsen...
Echt!? Man muss multipart requests parsen? Musste ich bis jetzt noch in keinem CGI Skript machen.
Python lässt sich wegen der Syntax (Einrückung bestimmt Programmstruktur) nicht so einfach in HTML einbetten,...
Ney. Das stimmt so nicht. Python lässt sich genauso gut in HTML Code einbetten wie PHP auch. Beispiele dafür sind PSP, Cheetah, Spyce und andere.
Doch das stimmt so. Ich sagte nicht das es unmöglich ist, sondern nur nicht so einfach. Darum gibt's bei vielen Template-Modulen nur "eingeschränktes" Python. Wenn die Einrückungstiefe wichtig ist, dann kann man eben nicht so einfach HTML und Python mischen. Wenn man dann noch die Datei mal in einem WYSIWYG HTML-Editor bearbeitet dann kann man Probleme bekommen, die man bei PHP nicht hätte.

Da es guter Stil ist Logik und Präsentation zu trennen empfinde ich diese Einschränkung aber eher als Vorteil.

Verfasst: Freitag 3. Februar 2006, 11:04
von jens
Im übrigen hab ich mal ein kleines HelloWorld-Tutorial mit WSGI/Colubrid im Wiki erstellt: [wiki]Colubrid/Hello World[/wiki]

IMHO sollte kein oder nur ganz wenig Python-Code in einem Template sitzten... Höchstens kleinigkeiten für eine Schleifenbearbeitung...

Verfasst: Freitag 3. Februar 2006, 11:08
von mitsuhiko
BlackJack hat geschrieben:
blackbird hat geschrieben:
BlackJack hat geschrieben:Ich denke wenn man es für den Anfang einfach haben will, so ähnlich wie PHP, dann sollte man mit CGI anfangen.
Sollte man nicht.
Sollte man doch. Was bleibt denn anderes übrig wenn man partout keine Webframeworks verwenden möchte? Diese Anforderung stammt ja nicht von mir.
Wer sagt den, dass man für WSGI ein Framework verwenden muss? Muss man genauso wenig wie für CGI :roll:
Für eine CGI Anwendung muss man in der Regel viel nervtötendes erledigen. Beispielsweise multipart requests parsen...
Echt!? Man muss multipart requests parsen? Musste ich bis jetzt noch in keinem CGI Skript machen.
Noch nie mit Dateiuploads gearbeiten? Und wenn du meinst, dass du mal schnell ein Cookie Handling mit CGI machst endet das nunmal in einem etwas längeren Skript. Header nach dem Content senden bearbeiten? Ist auch lustig mit CGI. Muss mal halt einen Buffer machen. Geht auch alles, aber da kann ich auch gleich WSGI nehmen...
Python lässt sich wegen der Syntax (Einrückung bestimmt Programmstruktur) nicht so einfach in HTML einbetten,...
Ney. Das stimmt so nicht. Python lässt sich genauso gut in HTML Code einbetten wie PHP auch. Beispiele dafür sind PSP, Cheetah, Spyce und andere.
Doch das stimmt so. Ich sagte nicht das es unmöglich ist, sondern nur nicht so einfach. Darum gibt's bei vielen Template-Modulen nur "eingeschränktes" Python. Wenn die Einrückungstiefe wichtig ist, dann kann man eben nicht so einfach HTML und Python mischen. Wenn man dann noch die Datei mal in einem WYSIWYG HTML-Editor bearbeitet dann kann man Probleme bekommen, die man bei PHP nicht hätte.
Du hast nicht wirklich eine Ahnung von was du redest oder? Das mit Python Code in HTML hat absolut nichts mit der Einrückung oder ähnlichem zu tun. Und das viele Tempalte Engines nur ein Subset von Python kennen hat noch weniger mit der Einrückung oder sowas zu tun. Für Jinja beispielseweise habe ich absichtlich interpretierende Templates, weil python in templates nicht mal im Ansatz so praktisch ist wie eine überlege Tempalte Sprache, die ihre eigene Syntax mitbringt.

Also sehe wir uns mal die Python Templates an, die es gibt. Da hätten wir mal zu allererst PSP. Unterstützt Python ausnahmslos. Weiter gehts mit spyce. Auch wie denkt die Template engine den kompletten Python Sprachbereich ab, den es gibt. Cheetah? Auch in diesem Fall haben wir Zugriff auf den ganzen Sprachgebraucht, aber hier schon leichte Ansätze von Template spezifischen Funktionen. Weiter gehts mit kid. Trotz XML Ansatz auch hier kompletten Zugriff auf alle Python Funktionen. Jinja, hier ist genauso wie bei django templates, SimpleTAL, HTMLTemplate, pyTempl, Spytee und Nevow eine eigene Syntax mit eigenen davorgeschalteten Interpreter bzw einer Klasse, die in Python Code umwandelt. Und wenn man auf PHP schaut sieht man, dass die PHP Entwickler auch lieber diesen Weg wählen, Smarty ist hier das Beste Beispiel.

Und nein. Das hat alles nichts mit der Einrückung zu tun :roll:
Da es guter Stil ist Logik und Präsentation zu trennen empfinde ich diese Einschränkung aber eher als Vorteil.
Da stimme ich dir zu, aber nur in der Hinsicht, dass die Trenung gut ist. denn die Einschränkung sehe ich nicht.

Verfasst: Freitag 3. Februar 2006, 11:45
von N317V
Erstmal vielen Dank BlackJack und vor allem blackbird! Das bringt schon ein wenig mehr Licht ins Dunkel. Das Problem ist IMHO einfach, dass man eine einfach Frage zu Webentwicklung stellt und gleich mit einem Arsenal an Schlagwörtern und zugehörigen Ratschlägen und/oder Warnungen erschlagen wird. Seht Euch doch nochmal den Eingangspost an! banthrass geht es ähnlich wie mir und wohl auch vielen anderen:

1. Ich hab einen funktionstüchtigen Webserver (Apache), mit dem ich sehr zufrieden bin. Ich will keinen zweiten Webserver, keinen weiteren Port aufmachen, nichts dergleichen.
2. Ich kann und will mich nicht durch die Dokumentation von 10 oder 20 verschiedenen Frameworks, Middlewares oder sonstwas arbeiten. Ich kann und will auch nicht jedes mal testweise installieren um dann zu sehen, dass es doch nicht das richtige war. Ich will überhaupt nur was installieren, wenn es unbedingt nötig ist. Python hab ich ja schon und Apache auch. Wenn ich noch was brauche, kommt automatisch die Frage "Wofür?" und wenn die Antwort darauf länger als eine Minute erfordert, brauch ich es wahrscheinlich nicht. Ich will keine Lösungen für Probleme, die ich noch gar nicht hab.
3. Ich will, dass Apache auf Anfrage irgendwie (wie, ist mir ersteinmal völlig egal) ein Python-Script startet und dessen Output als Antwort auf die Anfrage zurückgibt. Dass man das dann noch aufbohren und/oder vereinfachen kann ist mir vollkommen klar. Darüber mach ich mir dann später Gedanken! Wenn ich das jetzt richtig verstanden habe, brauch ich dafür einen wrapper.
4. (Gilt für banthrass möglicherweise nicht) Ich will eine saubere Trennung von Logik und Präsentation. Kein Code im Template!

Kurz gesagt, das Problem ist: Ich finde einfach keinen Anfang in all dem Wirrwarr. Womit *muss* ich mich näher beschäftigen? Was *kann* ich mir ansehen, wenn meine Anforderungen steigen?

EDIT: Danke auch an jens für das Beispiel im Wiki! Langsam wird es in dieser Richtung heller :-)

Verfasst: Freitag 3. Februar 2006, 11:50
von jens
OK, du kannst natürlich, wie ich es auch gemacht hab, einfach nur pure-Python-CGI benutzten... Alles selber machen usw.... Das ist ja auch nicht schlimm, meine Webseiten laufen mit PyLucid als CGI ganz nett...
Nur das dumme an CGI ist, das es langsam wird, wenn mehr Traffic da ist, weil der Python-Interpreter für jeden Request/Client einzeln gestartet wird... Somit eine recht große Belastung für den Server...
Mit WSGI hast du allerdings später die Möglichkeit was anderes als CGI, also modPython, fastCGI ect. zu nutzten. Dafür brauchst du deine Anwenung i.d.R. nicht umschreiben. Das ist der große Vorteil.

Anfangen kannst du ja mit WSGI auch als normales CGI. Siehe [wiki]Colubrid/Hello World[/wiki]
Du hast später aber mehr Möglichkeiten mehr zu machen, wenn du von anfang an auf WSGI setzt...

Verfasst: Freitag 3. Februar 2006, 13:08
von tabellar
N317V hat geschrieben:...
1. Ich hab einen funktionstüchtigen Webserver (Apache), mit dem ich sehr zufrieden bin. Ich will keinen zweiten Webserver, keinen weiteren Port aufmachen, nichts dergleichen.
2. Ich kann und will mich nicht durch die Dokumentation von 10 oder 20 verschiedenen Frameworks, Middlewares oder sonstwas arbeiten. Ich kann und will auch nicht jedes mal testweise installieren um dann zu sehen, dass es doch nicht das richtige war. Ich will überhaupt nur was installieren, wenn es unbedingt nötig ist. Python hab ich ja schon und Apache auch. Wenn ich noch was brauche, kommt automatisch die Frage "Wofür?" und wenn die Antwort darauf länger als eine Minute erfordert, brauch ich es wahrscheinlich nicht. Ich will keine Lösungen für Probleme, die ich noch gar nicht hab.
3. Ich will, dass Apache auf Anfrage irgendwie (wie, ist mir ersteinmal völlig egal) ein Python-Script startet und dessen Output als Antwort auf die Anfrage zurückgibt. Dass man das dann noch aufbohren und/oder vereinfachen kann ist mir vollkommen klar. Darüber mach ich mir dann später Gedanken! Wenn ich das jetzt richtig verstanden habe, brauch ich dafür einen wrapper.
4. (Gilt für banthrass möglicherweise nicht) Ich will eine saubere Trennung von Logik und Präsentation. Kein Code im Template!
Ok, nochmal zurück zu den Anfängen... :wink: Um bei Deinem laufenden System ein Python Skript zu starten, ist dies wohl die einfachste Art... :)


Code: Alles auswählen

#!/usr/bin/env python
# -*- coding: utf-8 -*-

print "Content-type: text/html"
print ""

print "Hello World!"
Den gezeigten Code als Datei helloWorld.py speichern und in das cgi-bin Verzeichnis vom Apache speichern. Mit dem Aufruf http://localhost/cgi-bin/helloWorld.py solltest Du dann das "Hello World!" sehen (Dateirechte beachten!).

Tabellar

PS:
Darauf kann man dann all die tollen Dinge von oben aufbauen...

Verfasst: Freitag 3. Februar 2006, 14:10
von N317V
@tabellar:

Traumhaft! Ich wusste doch, dass es einfach ist! :-) Genau das muss die allererste Antwort auf die Frage nach Python im Web sein. banthrass hatte ja auch geschrieben, dass er "Neuling" ist. Als Zweites kann dann IMHO der Hinweis auf unterschiedliche Interfaces, somit WSIG und schließlich Colubrid kommen.

Leicht OT: Was ist Colubrid eigentlich für ein komischer Name?

Verfasst: Freitag 3. Februar 2006, 17:44
von mitsuhiko
N317V hat geschrieben:Traumhaft! Ich wusste doch, dass es einfach ist! :-) Genau das muss die allererste Antwort auf die Frage nach Python im Web sein. banthrass hatte ja auch geschrieben, dass er "Neuling" ist. Als Zweites kann dann IMHO der Hinweis auf unterschiedliche Interfaces, somit WSIG und schließlich Colubrid kommen.
Colubrid == WSGI kompatibel. WSGI ist nur das, was du auch gerade oben mit dem kleinen Skript gemacht hast, nur halt mit mehr System dahinter.
Leicht OT: Was ist Colubrid eigentlich für ein komischer Name?
http://en.wikipedia.org/wiki/Colubrid

zu Deutsch auch Natter

Verfasst: Samstag 4. Februar 2006, 00:03
von BlackJack
blackbird hat geschrieben:
BlackJack hat geschrieben:
blackbird hat geschrieben:
BlackJack hat geschrieben:Ich denke wenn man es für den Anfang einfach haben will, so ähnlich wie PHP, dann sollte man mit CGI anfangen.
Sollte man nicht.
Sollte man doch. Was bleibt denn anderes übrig wenn man partout keine Webframeworks verwenden möchte? Diese Anforderung stammt ja nicht von mir.
Wer sagt den, dass man für WSGI ein Framework verwenden muss? Muss man genauso wenig wie für CGI :roll:
Na dann halt WSGI. (Ich gehe jetzt mal davon aus das Colubrid und web.py WSGI ohne viel Framework drumherum anbieten!?)
Echt!? Man muss multipart requests parsen? Musste ich bis jetzt noch in keinem CGI Skript machen.
Noch nie mit Dateiuploads gearbeiten?
Nein.
Und wenn du meinst, dass du mal schnell ein Cookie Handling mit CGI machst endet das nunmal in einem etwas längeren Skript.
Das ändert sich mit WSGI? Cookies und Sessions sind da auch nicht dabei.
Header nach dem Content senden bearbeiten? Ist auch lustig mit CGI. Muss mal halt einen Buffer machen. Geht auch alles, aber da kann ich auch gleich WSGI nehmen...
Ist auch unheimlich schwer `StringIO` zu importieren um die Daten zwischen zu speichern.
Python lässt sich wegen der Syntax (Einrückung bestimmt Programmstruktur) nicht so einfach in HTML einbetten,...
Ney. Das stimmt so nicht. Python lässt sich genauso gut in HTML Code einbetten wie PHP auch. Beispiele dafür sind PSP, Cheetah, Spyce und andere.
Doch das stimmt so. Ich sagte nicht das es unmöglich ist, sondern nur nicht so einfach. Darum gibt's bei vielen Template-Modulen nur "eingeschränktes" Python. Wenn die Einrückungstiefe wichtig ist, dann kann man eben nicht so einfach HTML und Python mischen. Wenn man dann noch die Datei mal in einem WYSIWYG HTML-Editor bearbeitet dann kann man Probleme bekommen, die man bei PHP nicht hätte.
Du hast nicht wirklich eine Ahnung von was du redest oder? Das mit Python Code in HTML hat absolut nichts mit der Einrückung oder ähnlichem zu tun. Und das viele Tempalte Engines nur ein Subset von Python kennen hat noch weniger mit der Einrückung oder sowas zu tun.
Woran liegt es dann?
Also sehe wir uns mal die Python Templates an, die es gibt. Da hätten wir mal zu allererst PSP. Unterstützt Python ausnahmslos. Weiter gehts mit spyce. Auch wie denkt die Template engine den kompletten Python Sprachbereich ab, den es gibt.
Zu PSP kann ich nix sagen, aber bei Spyce bekommst Du Probleme weil ``[[`` und ``]]`` für HTML-Editoren keine besondere Bedeutung haben. Wenn das irgendwo im Text steht und nicht zufällig in `<pre>` Tags, kann einem ein WYSIWYG-Editor Probleme bereiten.
Cheetah? Auch in diesem Fall haben wir Zugriff auf den ganzen Sprachgebraucht, aber hier schon leichte Ansätze von Template spezifischen Funktionen. Weiter gehts mit kid. Trotz XML Ansatz auch hier kompletten Zugriff auf alle Python Funktionen.
Okay, meine beiden Favoriten. Fangen wir bei Cheetah an: wo bitteschön siehst Du Python in den Templates? Das ist eine eigene, zugegebenermassen sehr Python-ähnliche Sprache, die erst in Python übersetzt wird. Unter anderem gibt es für die ganzen "Blöcke" wie ``#if``, ``#for`` usw. die zugehörigen ``#end`` Schlüsselwörter eben genau um das Problem zu umgehen, dass man in einem Template nicht auf signifikante Einrückung angewiesen sein möchte.

Bei `kid` kann man ganz gut Python Quelltext unterbringen, da ist die Ausgabe von "Text" aber viel restriktiver als bei PHP. Man kann nicht einfach so Text ausgeben sondern nur gültiges XML einfügen. IMHO für eine XML-Template Sprache eine sehr nützliche "Einschränkung".
Jinja, hier ist genauso wie bei django templates, SimpleTAL, HTMLTemplate, pyTempl, Spytee und Nevow eine eigene Syntax mit eigenen davorgeschalteten Interpreter bzw einer Klasse, die in Python Code umwandelt. Und wenn man auf PHP schaut sieht man, dass die PHP Entwickler auch lieber diesen Weg wählen, Smarty ist hier das Beste Beispiel.
Hm, also kann man bei den Template Mechanismen in dem Absatz keinen Python Quelltext wie in PHP einfügen. Die unterstützen also mein Ausgangsargument. Danke.
Da es guter Stil ist Logik und Präsentation zu trennen empfinde ich diese Einschränkung aber eher als Vorteil.
Da stimme ich dir zu, aber nur in der Hinsicht, dass die Trenung gut ist. denn die Einschränkung sehe ich nicht.
Schön für Dich. Leute die von PHP kommen und Smarty schon so komisch umständlich empfanden, sehen das aber als Einschränkung.

Verfasst: Samstag 4. Februar 2006, 09:15
von mitsuhiko
BlackJack hat geschrieben:
blackbird hat geschrieben:
BlackJack hat geschrieben:
blackbird hat geschrieben:
BlackJack hat geschrieben:Ich denke wenn man es für den Anfang einfach haben will, so ähnlich wie PHP, dann sollte man mit CGI anfangen.
Sollte man nicht.
Sollte man doch. Was bleibt denn anderes übrig wenn man partout keine Webframeworks verwenden möchte? Diese Anforderung stammt ja nicht von mir.
Wer sagt den, dass man für WSGI ein Framework verwenden muss? Muss man genauso wenig wie für CGI :roll:
Na dann halt WSGI. (Ich gehe jetzt mal davon aus das Colubrid und web.py WSGI ohne viel Framework drumherum anbieten!?)
Ja. :roll:
Und wenn du meinst, dass du mal schnell ein Cookie Handling mit CGI machst endet das nunmal in einem etwas längeren Skript.
Das ändert sich mit WSGI? Cookies und Sessions sind da auch nicht dabei.
Ja und? Aber dank dem Middleware Konzept kannst du einfach mehrere Teile aneinanderreihen und du hast Cookie/Session Handling. Und da gibts bereits mehr als genug fertige Konzepte...
Also sehe wir uns mal die Python Templates an, die es gibt. Da hätten wir mal zu allererst PSP. Unterstützt Python ausnahmslos. Weiter gehts mit spyce. Auch wie denkt die Template engine den kompletten Python Sprachbereich ab, den es gibt.
Zu PSP kann ich nix sagen, aber bei Spyce bekommst Du Probleme weil ``[[`` und ``]]`` für HTML-Editoren keine besondere Bedeutung haben. Wenn das irgendwo im Text steht und nicht zufällig in `<pre>` Tags, kann einem ein WYSIWYG-Editor Probleme bereiten.
Und das hat natürlich mit der Einrückung zu tun :roll:
Cheetah? Auch in diesem Fall haben wir Zugriff auf den ganzen Sprachgebraucht, aber hier schon leichte Ansätze von Template spezifischen Funktionen. Weiter gehts mit kid. Trotz XML Ansatz auch hier kompletten Zugriff auf alle Python Funktionen.
Okay, meine beiden Favoriten. Fangen wir bei Cheetah an: wo bitteschön siehst Du Python in den Templates? Das ist eine eigene, zugegebenermassen sehr Python-ähnliche Sprache, die erst in Python übersetzt wird. Unter anderem gibt es für die ganzen "Blöcke" wie ``#if``, ``#for`` usw. die zugehörigen ``#end`` Schlüsselwörter eben genau um das Problem zu umgehen, dass man in einem Template nicht auf signifikante Einrückung angewiesen sein möchte.
Ja logisch. Aber es ist doch scheiß egal ob du für deine Syntax jetzt #if und #end hast, oder ob du <?php if () { ?> und <?php } ?> hast. Aber ich hab Zugriff auf die komplette Sprache von Pyhton, was übrigens keine "python ähnliche Sprache", sondern Python ist.

Aber wenn du willst schreib dir eine Sprache, die Einrückungen haben will :roll:
Bei `kid` kann man ganz gut Python Quelltext unterbringen, da ist die Ausgabe von "Text" aber viel restriktiver als bei PHP. Man kann nicht einfach so Text ausgeben sondern nur gültiges XML einfügen. IMHO für eine XML-Template Sprache eine sehr nützliche "Einschränkung".
PHP ist KEINE XML Template Sprache. PHP ist nichtmal eine brauchbare Template Engine. Smarty gibts ja nicht ohne Grund.
Jinja, hier ist genauso wie bei django templates, SimpleTAL, HTMLTemplate, pyTempl, Spytee und Nevow eine eigene Syntax mit eigenen davorgeschalteten Interpreter bzw einer Klasse, die in Python Code umwandelt. Und wenn man auf PHP schaut sieht man, dass die PHP Entwickler auch lieber diesen Weg wählen, Smarty ist hier das Beste Beispiel.
Hm, also kann man bei den Template Mechanismen in dem Absatz keinen Python Quelltext wie in PHP einfügen. Die unterstützen also mein Ausgangsargument. Danke.
Ganz ehrlich hab ich die Schnauze voll mit dir zu Diskuttieren. Ich will dir nur sagen, dass wirklich durchdachte Template Engines _Keinen_ Zugriff auf Sprachelemente bieten. Alleine schon wegen der Sicherheit.
Da es guter Stil ist Logik und Präsentation zu trennen empfinde ich diese Einschränkung aber eher als Vorteil.
Da stimme ich dir zu, aber nur in der Hinsicht, dass die Trenung gut ist. denn die Einschränkung sehe ich nicht.
Schön für Dich. Leute die von PHP kommen und Smarty schon so komisch umständlich empfanden, sehen das aber als Einschränkung.[/quote]
Das sind dann die Leute, die das Konzept von Code/Template Trennung nicht verstanden haben. :roll:

Verfasst: Samstag 4. Februar 2006, 12:32
von XT@ngel
Ganz ehrlich hab ich die Schnauze voll mit dir zu Diskuttieren
:roll:
Soviel zum Thema; - Vergleich Äpfel mit Birnen
Wenn man keinen eigenen Server hat ist man mit Python beim Theme Webentwicklung recht eingeschränkt und daran ändert auch WSGI nichts.

Da kann es noch soviel an Frameworks und Application Server geben am Ende muss ich mein Script doch als cgi beim billig provider laufen lassen ;)

PSP, Django Turbogears, python-cgi, mod_python, Zope - und ich wollt nur ein Gästebuch
:mrgreen:

MfG
Andreas

Verfasst: Sonntag 5. Februar 2006, 01:25
von BlackJack
Und wenn du meinst, dass du mal schnell ein Cookie Handling mit CGI machst endet das nunmal in einem etwas längeren Skript.
Das ändert sich mit WSGI? Cookies und Sessions sind da auch nicht dabei.
Ja und?
Du hattest CGI unter anderem mit dem Argument abgelehnt, dass man dort Cookies selbst verwalten muss und stattdessen WSGI vorgeschlagen. Nur das man dort Cookies auch selbst verwalten muss.
Zu PSP kann ich nix sagen, aber bei Spyce bekommst Du Probleme weil ``[[`` und ``]]`` für HTML-Editoren keine besondere Bedeutung haben. Wenn das irgendwo im Text steht und nicht zufällig in `<pre>` Tags, kann einem ein WYSIWYG-Editor Probleme bereiten.
Und das hat natürlich mit der Einrückung zu tun :roll:
Ja. Ein HTML-Editor darf Text, der zum Beispiel nur in <p> Tags steht, als "Fliesstext" umformatieren. Python-Quelltext überlebt das nicht. Wegen der signifikanten Einrückung.
Fangen wir bei Cheetah an: wo bitteschön siehst Du Python in den Templates? Das ist eine eigene, zugegebenermassen sehr Python-ähnliche Sprache, die erst in Python übersetzt wird. Unter anderem gibt es für die ganzen "Blöcke" wie ``#if``, ``#for`` usw. die zugehörigen ``#end`` Schlüsselwörter eben genau um das Problem zu umgehen, dass man in einem Template nicht auf signifikante Einrückung angewiesen sein möchte.
Ja logisch. Aber es ist doch scheiß egal ob du für deine Syntax jetzt #if und #end hast, oder ob du <?php if () { ?> und <?php } ?> hast.
Natürlich ist das egal. Eben um das zu ermöglichen benutzt Cheetah kein Python sondern eine eigene Sprache.
Aber ich hab Zugriff auf die komplette Sprache von Pyhton, was übrigens keine "python ähnliche Sprache", sondern Python ist.
Das was man in Cheeta Templates einbettet ist kein Python. Versuch mal den Python-Interpreter ``#if $foo`` ausführen zu lassen. Und ``#repeat`` oder ``#unless`` gibt's in Python auch nicht als Schlüsselworte, nicht mal ohne das führende '#'.
Aber wenn du willst schreib dir eine Sprache, die Einrückungen haben will :roll:
Häh? Will ich nicht.
Bei `kid` kann man ganz gut Python Quelltext unterbringen, da ist die Ausgabe von "Text" aber viel restriktiver als bei PHP. Man kann nicht einfach so Text ausgeben sondern nur gültiges XML einfügen. IMHO für eine XML-Template Sprache eine sehr nützliche "Einschränkung".
PHP ist KEINE XML Template Sprache.
Hat das jemand behauptet?
PHP ist nichtmal eine brauchbare Template Engine. Smarty gibts ja nicht ohne Grund.
Sehe ich auch so.
Jinja, hier ist genauso wie bei django templates, SimpleTAL, HTMLTemplate, pyTempl, Spytee und Nevow eine eigene Syntax mit eigenen davorgeschalteten Interpreter bzw einer Klasse, die in Python Code umwandelt.
Hm, also kann man bei den Template Mechanismen in dem Absatz keinen Python Quelltext wie in PHP einfügen. Die unterstützen also mein Ausgangsargument. Danke.
Ganz ehrlich hab ich die Schnauze voll mit dir zu Diskuttieren. Ich will dir nur sagen, dass wirklich durchdachte Template Engines _Keinen_ Zugriff auf Sprachelemente bieten. Alleine schon wegen der Sicherheit.
Da bin ich ganz Deiner Meinung.
Da es guter Stil ist Logik und Präsentation zu trennen empfinde ich diese Einschränkung aber eher als Vorteil.
Da stimme ich dir zu, aber nur in der Hinsicht, dass die Trenung gut ist. denn die Einschränkung sehe ich nicht.
Schön für Dich. Leute die von PHP kommen und Smarty schon so komisch umständlich empfanden, sehen das aber als Einschränkung.
Das sind dann die Leute, die das Konzept von Code/Template Trennung nicht verstanden haben. :roll:
Ebenfalls ganz Deiner Meinung.

Verfasst: Sonntag 5. Februar 2006, 03:37
von N317V
XT@ngel hat geschrieben:
Ganz ehrlich hab ich die Schnauze voll mit dir zu Diskuttieren
:roll:
Soviel zum Thema; - Vergleich Äpfel mit Birnen
Wenn man keinen eigenen Server hat ist man mit Python beim Theme Webentwicklung recht eingeschränkt und daran ändert auch WSGI nichts.

Da kann es noch soviel an Frameworks und Application Server geben am Ende muss ich mein Script doch als cgi beim billig provider laufen lassen ;)

PSP, Django Turbogears, python-cgi, mod_python, Zope - und ich wollt nur ein Gästebuch
:mrgreen:

MfG
Andreas
Und ich hab auch jemanden gefunden, der meiner Meinung ist. :-)
Ich liebe das Internet! :lol:

Verfasst: Sonntag 5. Februar 2006, 11:47
von tabellar
Leute, Leute, lasst doch die Kirche im Dorf :D . Jeder bringt hier sein Wissen bestmöglich mit ein. Diskutieren und Enthusiasmus sind ja schön und gut, aber
der rote Faden und der entsprechende Ton sollten nicht verloren gehen ... ;-)

Tabellar

Re: Python und Webprogrammierung [neuling]

Verfasst: Mittwoch 1. März 2006, 20:02
von synopia
Auch auf die Gefahr hin, dass ich mir ein paar Feinde hier im Python-Forum mache, schreib ich jetzt mal hier Meinung hin :mrgreen:
banthrass hat geschrieben:...Naja da denk ich mir "warum PHP wenn ich python was neues lernen kann, was den selben effekt hat...
Ok, also ist es dir erstmal grundsätzlich egal, welche Skriptsprache du einsetzten willst, nur nicht PHP (was ich im ürbigen vollkommen verstehen kann :-D)
banthrass hat geschrieben:...Ich hab bisher ein grundlegendes Verständnissproblem bei python. Kann mir jemand sagen wie ich python in HTML einbinden kann? Wie könnte ich z.B. einen Adminpanel für meine seite realisieren? Gibt es eine ähnliche inculde funktion wie in PHP? Kann ich python ganz nomal in einem texteditor einfügen, die page hochladen und es läuft oder ist das ein spezielles Format gefragt? Wenn ja wie binde ich dieses Format oder diese Datein ein? Es wäre nett wenn mir jemand die grundlegen dinge zur Python Webprogrammierung mal erläutern könnte. also wie genau baue ich einfach eine HTML seite wo z.B. "Hallo Welt" drin steht. Wie und Wo muss ich speichern, welche Einstellungen sind beim Apache (xampp) nötig. Muss ich was bei dem arbeiten von Linux und Win etwas beachten (zuhause Linux auf der arbeit win2k)?...


Wenn mich jemand genau das fragen würde, würde ich ihm immer:

http://www.rubyonrails.com

empfehlen. Ja Rails ist nicht Python, sondern Ruby, aber: Mit Ruby und Rails erhältst du alles, was du zum Entwickeln von Webanwendungen brauchst. Es ist einfach zu installieren (für Win gibts ein One-Click-Installer, für Linux entsprechende Packete (lang lebe apt!)) und es ist alles dabei was man braucht (ORM für Datenbank, simple Templatesprache, Klare Trennung zwischen Modell und View, Unit-Tests, ...) und insgesamt verdammt einfach zu bedienen und, das allerwichtigste, es macht Spass damit zu entwickeln. Das ist mir nach einem grösserem J2EE Projekt sowas von klar geworden... ich hab mich nach Alternativen umgeschaut, und bin auch zuerst auf Python gestoßen. Aber bei Python wars leider ähnlich wie bei J2EE. 1000 halbe Projekte, einige sehr wirre Quasistandards und insgesamt einfach unglaublich unübersichtlich... In meiner Verzweiflung hab ich weitergesucht und bin kurz darauf auf RoR gestoßen und muss sagen, ich bin wirklich beeindruckt davon.

Also an alle, die demnächst ein neues Webprojekt anfangen und denen es um effektive Entwicklung und Umsetztung geht, unbedingt mal über den Tellerrand schauen! Es lohnt sich.

Verfasst: Mittwoch 1. März 2006, 20:05
von jens
Dabei sollte man allerdings nicht außer acht lassen, das Ruby noch seltener als Python bei normalen Web-Space anzutreffen ist. s.: http://wiki.python.de/Python_Webspace

Wie läuft RoR denn? Mit CGI?