Seite 1 von 2

Verfasst: Sonntag 1. April 2007, 19:33
von mitsuhiko
BlackJack hat geschrieben:Ich verstehe diesen ganzen WSGI-Hype auch nicht wirklich. Das ist eine Schnittstelle, die für Entwickler von Webframeworks gedacht ist (oder war), d.h. einem "Endkunden", der Webseiten schreiben will, sollte es eigentlich egal sein. Ausser man will das 100000ste Webframework entwickeln.
Karrigell ist kein Framework?

Verfasst: Sonntag 1. April 2007, 21:43
von BlackJack
Ich gehe mal davon aus, Du kannst die Frage selbst mit "Ja" beantworten. Warum fragst Du also?

Verfasst: Freitag 6. April 2007, 18:10
von mq
Hm. Fuer mich sieht das irgendwie mehr nach "PHP fuer Python" als nach einem Framework aus. Ist das wirklich so oder taeusche ich mich da?

Verfasst: Freitag 6. April 2007, 18:15
von mitsuhiko
gerold hat geschrieben:Der Preis für WSGI ist derzeit viel zu hoch!
Ja? Ich kann keinen merklichen Overhead erkennen.
Es ist alles *viel* komplizierter geworden als es sein müsste. Statt wie bei Karrigell oder PHP, einfach eine Datei mit einer vorgegebenen Endung zum Server hochzuladen, muss man bei den derzeitigen WSGI-Lösungen diese Datei auch noch in irgendeine Anwendungslogik integrieren.
Dann versuch mal eine Karrigell-Anwendung, ein MoinMoin, ein django portal, eine trac, eine pocoo installation und eine cherrypy2 Anwendung auf ein und demselben Server zu installieren. Wünsch dir jetzt schon viel Spaß.
Das ist es, was WSGI derzeit so unnütz verkompliziert. Man muss Bücher lesen, um auch nur eine funktionierende, dynamische Internetseite zum Apache hoch zu bekommen.
Kenn kein WSGI Buch. Leider.
Das Karrigell-Tar-Archiv entpackt man irgendwohin, startet ``karrigell.py`` und schon läuft der eingebaute (recht schnelle) Webserver. Alle PY-Seiten, die im untergeordneten ``webapps``-Ordner liegen, werden interpretiert und im Browser angezeigt, sobald die entsprechende URL aufgerufen wird. Einfacher geht es nicht! :D
Das kannst du mit WSGI Anwendungen auch. Ein WSGI Server ist mit python2.5 sogar schon mit in der stdlib.
Sobald ein WSGI-Framework so einfach zu verwenden ist, lasse ich mich gerne auf so ein WSGI-Framework ein, aber derzeit sind die Vorteile von Karrigell einfach enorm.
Bin immer noch auf der Suche nach den Vorteilen.

Verfasst: Freitag 6. April 2007, 18:15
von Leonidas
Ich habe die Anleitung nach [wiki]Erste Schritte mit Karrigell[/wiki] übertragen (man könnte auch transkopbiert sagen, denn ich habe den Text etwas dem Wiki-Stil angepasst). Die Seite ist im Moment leider nur sehr schwach im Wiki verlinkt, daher sind alle herzlich dazu aufgerufen die Siete dort zu verlinken, wo sie nützlich sein könnte.

Verfasst: Freitag 6. April 2007, 18:16
von mitsuhiko
BlackJack hat geschrieben:Ich gehe mal davon aus, Du kannst die Frage selbst mit "Ja" beantworten. Warum fragst Du also?
WSGI ist nicht für dich da, sondern für den Karrigell Entwickler.

Verfasst: Freitag 6. April 2007, 18:51
von jens
blackbird hat geschrieben:
Sobald ein WSGI-Framework so einfach zu verwenden ist, lasse ich mich gerne auf so ein WSGI-Framework ein, aber derzeit sind die Vorteile von Karrigell einfach enorm.
Bin immer noch auf der Suche nach den Vorteilen.
Der Vorteil dürfte der einfach Einstieg sein. Es ist schon denkbar, das man schneller ein erstes Ergebnis mit Karrigell erhält, als mit WSGI-Konformen Frameworks (wie TG, django oder colubrid). Zumindest für Leute die das erste mal eine Web-Anwendungen erstellen wollen.
So sieht es für mich jedenfalls aus, wenn ich mit [wiki]Erste Schritte mit Karrigell[/wiki]ansehe.

Aber dennoch kann und werde ich mich mit Karrigell ganz bestimmt nicht anfreunden :) Das Templatesystem gefällt mir überhaupt nicht... Aber jedem das seine...

Immer locker bleiben! :lol:

Verfasst: Freitag 6. April 2007, 18:52
von BlackJack
@blackbird: Äh, das weiss ich. Wenn Du meinen Text nochmal liest, den Du vor Deiner Frage zitiert hast, sollte das eigentlich ersichtlich sein.

Ich weiss immer noch nicht was die Frage und die Antwort bezwecken sollte!?

Verfasst: Freitag 6. April 2007, 18:56
von Leonidas
jens hat geschrieben:Das Templatesystem gefällt mir überhaupt nicht... Aber jedem das seine...
Hey, das hat ja gar kein Templatesystem... oder moment, das ist eigentlich nichts anderes als ein Templatesystem ;) Genauso wie PHP. 8) (Damit meine ich nur den PIH-Part. Der Karrigell-Service-Part erinnert mich nämlich sehr stark an CherryPy)

Verfasst: Freitag 6. April 2007, 20:28
von gerold
Leonidas hat geschrieben:Hey, das hat ja gar kein Templatesystem... oder moment, das ist eigentlich nichts anderes als ein Templatesystem ;) Genauso wie PHP. 8) (Damit meine ich nur den PIH-Part. Der Karrigell-Service-Part erinnert mich nämlich sehr stark an CherryPy)
Hi @ all!

Ich muss mich jetzt endlich vom Forum losreisen, denn heute habe ich außer Pyton-Forum nur Python-Forum hinter mir.

Aber ein paar Kleinigkeiten habe ich noch zu Karrigell zu sagen, bevor jeder glaubt, dass man damit nur wie mit PHP/ASP arbeiten kann.

Zusätzlich zum Stamm-System mit den PY-, PIH-, HIP- und KS-Dateien kann man die Vorlagensprache "Cheetah" (Dateiendung: TMPL) verwenden. Man ist also zum Glück nicht gezwungen sich auf PHP-Niveau zu begeben.

Ich habe mir vor Kurzem ein bischen Zeit genommen und habe das für mich so wertvolle Vorlagensystem TAL/METAL, das ich von Zope her kenne, in Karrigell integriert. Zum Glück gibt es eine recht gut verwendbare Schnittstelle zu diesem Vorlagensystem: --> SimpleTAL! Damit war es kein Problem.

Wer also TAL von Zope her kennt, der kommt mit diesem Vorlagensystem auch unter Karrigell schnell klar.

Leider sind die Beispiele und die Anleitung noch nicht fertig, deshalb wollte ich noch nichts genaues darüber schreiben. Aber jetzt wird darüber geredet, also muss ich zumindest mal das zeigen, was ich bis jetzt schon habe. Es ist noch nicht fehlerfrei und noch lange nicht fertig, aber ich habe mal den aktuellen Code auf den Firmenserver hochgeladen und den Karrigell-Server in einer Screen-Session gestartet. :-)

Die "SimpleTAL-Demo 1" soll aufzeigen, wie man TAL auch in einfachen, dynamischen HTML-Seiten einsetzen kann. Ich zeige den Quellcode der TAL-Seiten jeweils unterhalb der Seite an.

Die "SimpleTAL-Demo 2" ist dann schon eher für fortgeschrittene User. Darin wird die Verwendung von METAL demonstriert. Es gibt eine Hauptvorlage (METAL-Datei), die von den TAL-Dateien verwendet wird. Die TAL-Dateien füllen den Content über Slots in die Hauptvorlage. Genau so, wie man es von Plone her gewohnt ist.

Die in Karrigell integrierten Beispiele sind auch aktiviert. Diese findet man unter http://gelb.bcom.at:35682/demo/frame_tour_en.htm.

Karrigell ist eigentlich nur ein kleiner Webserver, der Python-Dateien und noch ein paar andere Dateitypen interpretiert und zurück gibt. Karrigell kümmert sich um die Sessions und um die Authentifizierung. Es ist kein großes Framework, aber es hat ein paar **entscheidende** Vorteile:

- Es liefert statische Seiten aus, ohne dass ich mich darum kümmern muss.

- Ich lade eine Datei hoch und schon kann ich darauf zugreifen. So wie man es von PHP her kennt. Ich muss diese nicht irgendwo in ein Hauptprogramm integrieren. Einfach die URL der Datei in den Browser eingeben, schon wird die Datei geparst, interpretiert und an den Browser geschickt.

- Mit der TAL-Integration werden Dateien mit der Endung ".tal" sofort als TAL-Dateien erkannt, interpretiert und zurück gegeben. Man muss diese nicht extra in einem Hauptprogramm anmelden. Trotzdem ist es möglich Python-Code für die Programmlogik zu hinterlegen. Legt man eine Datei mit der Endung ".talpy" an, die den gleichen Dateinamen hat wie die TAL-Datei, dann wird **zuerst** diese TALPY-Datei ausgeführt und mit den darin zur Verfügung gestellten Daten wird dann die TAL-Datei gefüttert. Es ist also ein KANN und kein MUSS.

Leider sind meine Beispiele noch nicht fertig und ich habe auch noch keine Anleitung dafür geschrieben. Deshalb kann ich jetzt noch niemanden zumuten, die Sache auszuprobieren. Wer aber trotzdem mal einen Blick auf den Quellcode werfen möchte findet diesen hier:
- http://gelb.bcom.at/trac/misc/browser/K ... _TAL/trunk
- http://gelb.bcom.at/~gerold/Karrigell_with_TAL.zip

mfg
Gerold
:-)

PS: Zu den anderen Beiträgen äußere ich mich morgen. :-)

Verfasst: Freitag 6. April 2007, 22:45
von Leonidas
gerold hat geschrieben:Aber ein paar Kleinigkeiten habe ich noch zu Karrigell zu sagen, bevor jeder glaubt, dass man damit nur wie mit PHP/ASP arbeiten kann.

Zusätzlich zum Stamm-System mit den PY-, PIH-, HIP- und KS-Dateien kann man die Vorlagensprache "Cheetah" (Dateiendung: TMPL) verwenden. Man ist also zum Glück nicht gezwungen sich auf PHP-Niveau zu begeben.
Ganz so schlimm ist PHP auch nicht, es hat mit Smarty auch ein Templatesystem, welches von der Syntax her ein wenig an das von Django erinnert.

Edit: Ich denke ich schreibe morgen die Gerolds bemerkungen zu einem weiteren Artikel im Wiki zusammen. Dann gibts ja richtig eine Artikelserie :D

Verfasst: Samstag 7. April 2007, 00:14
von mitsuhiko
Leonidas hat geschrieben:...Smarty auch ein Templatesystem, welches von der Syntax her ein wenig an das von Django erinnert.
Ich sag nur ptemplates.

Verfasst: Samstag 7. April 2007, 09:53
von gerold
blackbird hat geschrieben:
Leonidas hat geschrieben:...Smarty
ptemplates.
Hi!

Ich gebe zu, das hätte ich den PHP-Entwicklern nicht zugetraut. :oops:

mfg
Gerold
:-)

Verfasst: Samstag 7. April 2007, 10:58
von gerold
gerold hat geschrieben:PS: Zu den anderen Beiträgen äußere ich mich morgen. :-)
Hi!

Ich habe mir alle Beiträge noch einmal durchgelesen. Es gibt (fast) nichts zu was ich mich in den vorherigen Beiträgen nicht schon geäußert hätte. Deshalb habe ich hier auch nicht viel zu schreiben. :-)

@blackbird: Ein für mich wichtiger Punkt für die einfache Verwendung eines Frameworks oder Webserver oder wasauchimmer ist, dass ich als Entwickler oder Webdesigner eine Datei in einen Ordner stellen kann und diese Datei vom System sofort verwendet/ausgeliefert werden kann. Wenn ich eine PHP-Datei per FTP zum Webserver hochlade, dann kann ich das Ergebnis sofort mit dem Browser testen. Ich muss diese Datei nicht zuerst irgendwo anmelden und selber, im Code, vom Templating-System rendern lassen. Nein, das Framework/der Webserver soll sofort erkenen, dass eine neue Vorlage im Ordner liegt und diese nach Anforderung sofort interpretiert ausliefern.
Das ist es, was ich von einem Framework/Webserver verlange um unkompliziert arbeiten zu können. Das ist Luxus, den ich einfach haben möchte. Diesen Luxus ist jeder bereits von PHP her gewohnt. Niemand versteht sofort, warum man eine PY-Datei (damit meine ich jetzt nicht CGI) nicht einfach in einen Ordner legt und mir das dafür zuständige Framework nicht ohne weiteres das Ergebnis der ausgeführten Datei zurück liefert.

Beispiele:
Es kann doch nicht sein, dass ich mir vorher "Dekoratoren" rein ziehen muss, nur um ein paar dynamische Web-Seiten zu erstellen. (Damit möchte ich auf kein bestimmtes Framework anspielen. Das machen mehrere so.)

Es kann doch nicht sein, dass ich mich mit der Konfiguration des Apachen herumschlagen muss, oder komplizierte RE-Pattern angeben muss, nur um statische Seiten/Bilder ausgeliefert zu bekommen.

<leicht ironisch gemeint>
Die Hauptfrage von Anfängern ist doch immer die gleiche: Ich möchte meine Internetseiten mit Python erstellen. Wie geht das?

Die Hauptantwort darauf ist: Fange nicht mit Internetprogrammierung an. Das ist nicht so einfach wie du denkst. Lerne zuerst intensiv Python, dann bist du bereit, eines der übercoolen Webframeworks zu verwenden.

Was interessiert es mich wie hipp ich mit einem Framework AJAX-Seiten erstellen kann, wenn ich schon bei einfachsten Dingen mehr Arbeit damit habe als ich es vom alten PHP/FI her kenne. Und das war damals kein Zuckerschlecken...

Sogar Zope 2 ist in dieser Hinsicht noch einfacher als es manche (ich kenne nicht alle!) WSGI-Frameworks heute sind. Wenn Zope 2 mal installiert ist, dann schiebe ich eine Datei per FTP hoch und das Ding läuft. Auch ohne zusätzliche Arbeit.
</leicht ironisch gemeint>

Es geht noch weiter:
Es ist kein Problem Zope 2 in mehreren Versionen auf einem Server zu installieren. Das mach auch Sinn, denn ein Kunde bezahlt nur einmal für seine Website. Er bezahlt nichts für die Schwierigkeiten die man hat, wenn auf eine neue Frameworkversion umgestiegen wird.

Warum ist es dann so schwierig, wenn nicht sogar (fast) unmöglich, mehrere Versionen eines Trac oder eines MoinMoin auf einem Server zu installieren? Weil die Entwickler auf die (für mich blöde) Idee gekommen sind, das Framework mit distutils in den Python-Ordner zu installieren. Bei Zope 3 sind sie jetzt auf die selbe Idee gekommen. Keiner macht sich Gedanken darüber, wie schwierig es ist, mehrere Sites, die zu verschiedensten Zeiten entstanden sind, mit nur einer Framework-Version aktuell zu halten.

Ich will niemandem auf den Schlips treten (@blackbird: ich spiele auch nicht auf Colubrid an), aber es gibt ein paar Dinge, die ich nicht einsehe und erst mal abwarte, bis diese behoben sind. Es gibt leider noch viele Dinge, die die großen und auch viele kleine Python-Webframeworks kompliziert machen.

Warum kapiert niemand, dass wir zuerst mal etwas Einfaches brauchen, um Python den Webentwicklern schmackhaft zu machen. Wenn ich mich als PHP-Entwickler für Python interessieren würde und mir http://files.turbogears.org/video/20MinuteWiki2nd.mov ansehe, dann wird mich niemand davon abhalten, weiter in PHP zu entwickeln. http://www.djangoproject.com/documentation/tutorial01/ ist nicht besser. Da steigen die meisten schon bei "Database setup" aus.


Es ist Mittag. Ich muss mich ums Essen kümmern... :-)


Da habe ich mich wohl getäuscht. Ich dachte, ich hätte nicht mehr viel zu schreiben. :roll:

lg
Gerold
:-)

Verfasst: Samstag 7. April 2007, 11:02
von mitsuhiko
gerold hat geschrieben:Warum kapiert niemand, dass wir zuerst mal etwas Einfaches brauchen, um Python den Webentwicklern schmackhaft zu machen. Wenn ich mich als PHP-Entwickler für Python interessieren würde und mir http://files.turbogears.org/video/20MinuteWiki2nd.mov ansehe, dann wird mich niemand davon abhalten, weiter in PHP zu entwickeln. http://www.djangoproject.com/documentation/tutorial01/ ist nicht besser. Da steigen die meisten schon bei "Database setup" aus.
PHP Skript Kiddies sind auch nicht die Zielgruppe. Wer mal schnell eine 373313 webseite zusammenbasteln will ist bei python imho sowieso falsch. Wer richtige Webanwendungen entwickelt sollte sich dann doch einmal WSGI ansehen, wenn er nicht nach Fertigstellung auf die Schnauze fliegen will.

Verfasst: Samstag 7. April 2007, 11:13
von Leonidas
gerold hat geschrieben:Warum ist es dann so schwierig, wenn nicht sogar (fast) unmöglich, mehrere Versionen eines Trac oder eines MoinMoin auf einem Server zu installieren? Weil die Entwickler auf die (für mich blöde) Idee gekommen sind, das Framework mit distutils in den Python-Ordner zu installieren. Bei Zope 3 sind sie jetzt auf die selbe Idee gekommen. Keiner macht sich Gedanken darüber, wie schwierig es ist, mehrere Sites, die zu verschiedensten Zeiten entstanden sind, mit nur einer Framework-Version aktuell zu halten.
Mit setuptools geht das. Dort kann man einfach eine Version auswählen die man nutzen will, ebenso wie eine Default-Version, die genutzt wird denn nichts anderes da ist.

Und auch nicht alle Frameworks machen Probleme beim Update. Die liste der Änderungen hält sich zum Beispiel in Django von Release zu Release recht gering und das soll bis Version 1.0 auch so anhalten (danach eigentlich auch, was ich fast schon wieder traurig finde). Das hat sowohl positive als auch negative Seiten. Aber zumindest herrscht nicht permanente Verwirrung so wie bei TG. Ich kann quasi jeden Tag ein svn up machen und mit der neuesten Django-Version arbeiten, ohne Angst haben zu müssen, das irgendetwas auf einmal den Geist aufgibt.

Verfasst: Samstag 7. April 2007, 11:18
von BlackJack
@blackbird: Genau diese Beiträge verstehe ich nicht bzw. kommen mir immer so vor als wenn Du WSGI als Allheilmittel oder Religion verkaufen möchtest. Du schmeisst immer diese Abkürzung in den Raum, dabei ist WSGI eigentlich gar nicht benutzbar für jemanden der Webanwendungen programmieren will. Es sei denn, er möchte auch noch ein Framework dazuprogrammieren, weil wir uns ja offenbar schon einig sind, dass WSGI für Framework-Entwickler gedacht ist.

Andererseits kann man z.B. auch Karigell benutzen ohne nach Fertigstellung auf die Schnauze zu fliegen, was immer das bedeuten soll.

Verfasst: Samstag 7. April 2007, 11:35
von jens
blackbird hat geschrieben:
gerold hat geschrieben:Warum kapiert niemand, dass wir zuerst mal etwas Einfaches brauchen, um Python den Webentwicklern schmackhaft zu machen.
PHP Skript Kiddies sind auch nicht die Zielgruppe. Wer mal schnell eine 373313 webseite zusammenbasteln will ist bei python imho sowieso falsch. Wer richtige Webanwendungen entwickelt sollte sich dann doch einmal WSGI ansehen, wenn er nicht nach Fertigstellung auf die Schnauze fliegen will.
So wird sich allerdings keine Community bilden, wenn der Einstieg schon das können voraussetzt :roll:

WSGI muß man sich IMHO nur dann zwingend ansehen, wenn man ein neues Framework bauen will... Wenn man sich django nimmt und nach deren Doku Programmiert, braucht man von WSGI nichts wissen...

Verfasst: Samstag 7. April 2007, 12:06
von mitsuhiko
BlackJack hat geschrieben:@blackbird: Genau diese Beiträge verstehe ich nicht bzw. kommen mir immer so vor als wenn Du WSGI als Allheilmittel oder Religion verkaufen möchtest. Du schmeisst immer diese Abkürzung in den Raum, dabei ist WSGI eigentlich gar nicht benutzbar für jemanden der Webanwendungen programmieren will. Es sei denn, er möchte auch noch ein Framework dazuprogrammieren, weil wir uns ja offenbar schon einig sind, dass WSGI für Framework-Entwickler gedacht ist.
Es gibt zwei Arten von Anwendung entwickeln. Du machst eine Anwendung wie phpBB, die du an möglichst vielen Servern der Welt verwenden willst. Und dann gibts die Anwendung, die du nur auf dienem Server installierst. In letzterem Fall ist es dir warscheinlich egal, im ersten willst du wirklich, dass das überall läuft.

Niemand verlang von dir, dass du WSGI versteht. Aber wenn du deine Anwendung verteilen willst setzt du entweder auf WSGI auf oder nimmst ein Framework mit WSGI Unterstützung.

Ich kritisiere ja nur an Karrigell, dass es eben nicht WSGI kompatibel ist. Für Gerold hätte das keinen Unterschied, ihm ist es egal. Für ihn ändert sich ja nichts. Für mich würde sich sehr wohl was ändern. Ich könnte zb eine Karrigell mit einem Moin verheiraten ohne Probleme.

Verfasst: Samstag 7. April 2007, 16:02
von BlackJack
Ich habe WSGI also nicht verstanden. Wie dumm von mir. :-)

Wenn ich eine Anwendung schreiben will, die ich verteilen will, dann setze ich auf PHP auf. Das läuft nämlich so ziemlich überall.