Python und Webprogrammierung [neuling]

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
N317V
User
Beiträge: 504
Registriert: Freitag 8. April 2005, 13:23
Wohnort: München

Donnerstag 2. Februar 2006, 18:06

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
Es gibt für alles eine rationale Erklärung.
Außerdem gibt es eine irrationale.

Wie man Fragen richtig stellt
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Donnerstag 2. Februar 2006, 19:50

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...
TUFKAB – the user formerly known as blackbird
BlackJack

Donnerstag 2. Februar 2006, 23:09

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
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Freitag 3. Februar 2006, 04:43

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]
TUFKAB – the user formerly known as blackbird
BlackJack

Freitag 3. Februar 2006, 10:46

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.
Benutzeravatar
jens
Moderator
Beiträge: 8482
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Freitag 3. Februar 2006, 11:04

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...

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Freitag 3. Februar 2006, 11:08

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.
TUFKAB – the user formerly known as blackbird
N317V
User
Beiträge: 504
Registriert: Freitag 8. April 2005, 13:23
Wohnort: München

Freitag 3. Februar 2006, 11:45

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 :-)
Es gibt für alles eine rationale Erklärung.
Außerdem gibt es eine irrationale.

Wie man Fragen richtig stellt
Benutzeravatar
jens
Moderator
Beiträge: 8482
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Freitag 3. Februar 2006, 11:50

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...

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
tabellar
User
Beiträge: 186
Registriert: Mittwoch 4. September 2002, 15:28

Freitag 3. Februar 2006, 13:08

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...
N317V
User
Beiträge: 504
Registriert: Freitag 8. April 2005, 13:23
Wohnort: München

Freitag 3. Februar 2006, 14:10

@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?
Es gibt für alles eine rationale Erklärung.
Außerdem gibt es eine irrationale.

Wie man Fragen richtig stellt
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Freitag 3. Februar 2006, 17:44

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
TUFKAB – the user formerly known as blackbird
BlackJack

Samstag 4. Februar 2006, 00:03

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.
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Samstag 4. Februar 2006, 09:15

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:
TUFKAB – the user formerly known as blackbird
XT@ngel
User
Beiträge: 256
Registriert: Dienstag 6. August 2002, 14:36
Kontaktdaten:

Samstag 4. Februar 2006, 12:32

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
Antworten