Meine ersten Schritte mit Karrigell

[mitsuhiko]

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.

[jens]

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!

[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!?

[Leonidas]

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. (Damit meine ich nur den PIH-Part. Der Karrigell-Service-Part erinnert mich nämlich sehr stark an CherryPy)

[gerold]

Hey, das hat ja gar kein Templatesystem... oder moment, das ist eigentlich nichts anderes als ein Templatesystem Genauso wie PHP. (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.

[Leonidas]

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

[mitsuhiko]

...Smarty auch ein Templatesystem, welches von der Syntax her ein wenig an das von Django erinnert.

Ich sag nur ptemplates.

[gerold]

...Smarty

ptemplates.

Hi!

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

mfg
Gerold

[gerold]

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.

lg
Gerold

[mitsuhiko]

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.

[Leonidas]

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.

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

[jens]

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

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

[mitsuhiko]

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

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

[mitsuhiko]

Ich habe WSGI also nicht verstanden. Wie dumm von mir.

Du entwickelst auch keine Frameworks und der unteren Aussage nach auch keine Anwendungen.

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

Das ist die andere Möglichkeit. Fällt für mich aber Weg, da PHP ziemlich saugt.

[mitsuhiko]

So wird sich allerdings keine Community bilden, wenn der Einstieg schon das können voraussetzt

Vorausgesetzt du bist ein Anwendungsentwickler landst du früher oder später bei...

• Zope
• einem WSGI Framework
• WSGI selber

So gesehehen jeden Tag auf diversen IRC Channels. Warum? Weil du willst, dass deine Anwendung auf $Server problemlos läuft (gut, Zope ist eine Ausnahme, aber da sind auch andere Voraussetzungen dabei; Aber hey, in Zope3 kannst du WSGI Anwendungen einhängen)

Je nachdem ob du neu bist oder nicht gehst du mit einem Framework (vielleicht sogar Karrigell, hab beim Entwickler mal nach WSGI Unterstützung nachgefragt), oder setzt direkt auf WSGI auf, was natürlich viel schwerer ist.

Der Einstieg in die Python Webentwicklung ist überaus leicht denke ich. Mit django bist du viel schneller bei einem funktionierenden Blog als mit PHP. Hab den Versuch gemacht

[EnTeQuAk]

Der Einstieg in die Python Webentwicklung ist überaus leicht denke ich. Mit django bist du viel schneller bei einem funktionierenden Blog als mit PHP. Hab den Versuch gemacht

Wobei das aber auch von den Kenntnissen abhängt. Und du, denke ich, kennst ja PHP und Python recht gut

Wobei du recht hast. Bevor ich mich in PHP reinlernen müsste würde ich mir auch lieber Python aneignen und mit Django programieren.
Und es ist ja auch so, das Python einfach einfach aber auch kompliziert sein kan. Aber einfach einfach ist einfach gut

Aber ich glaube nur so nebenbei, das es hier doch mehr um Karrigell gehen soll, als um WSGI. Und Hey... blackbird, Knight of WSGI....
ich mag den Titel hi hi

(vielleicht sogar Karrigell, hab beim Entwickler mal nach WSGI Unterstützung nachgefragt)

Aber man kann auch zu weit gehen. Klar, WSGI-Unterstützung währe sicherlich super. Würde aber ne andere Struktur erfordern, wenn ich nicht ganz falsch liege.

Ich finde die Idee, so wie Karrigell ist, sehr gut. Hab auch schon ein wenig damit rumgespielt.
Ich finde ab und zu ma etwas, was andere Wege geht ist auch nicht schlecht

MfG EnTeQuAk

[jens]

Ich hab Karrigell mal ins Wiki aufgenommen: [wiki]Web Frameworks[/wiki]

Wäre schön, wenn jemand dazu noch was schreiben würdet
Btw. zu Pylons steht auch nix da

[Leonidas]

Ich hab Karrigell mal ins Wiki aufgenommen: [wiki]Web Frameworks[/wiki]

Ich möchte nicht, dass das wieder so ausartet wie die Seite mit den Template-Engines, wovon viele einfach zu wenig verbreitet sind.

Btw. zu Pylons steht auch nix da

Nein, und die Infors zu TurboGears sind auch outdated. Aber die Seite ist auch von geringer Qualität, muss man zugeben. Aber alles zu seiner Zeit.