Meine ersten Schritte mit Karrigell

Code-Stücke können hier veröffentlicht werden.
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Sonntag 1. April 2007, 19:33

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

Sonntag 1. April 2007, 21:43

Ich gehe mal davon aus, Du kannst die Frage selbst mit "Ja" beantworten. Warum fragst Du also?
Benutzeravatar
mq
User
Beiträge: 124
Registriert: Samstag 1. Januar 2005, 19:14

Freitag 6. April 2007, 18:10

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

Freitag 6. April 2007, 18:15

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.
TUFKAB – the user formerly known as blackbird
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Freitag 6. April 2007, 18:15

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.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Freitag 6. April 2007, 18:16

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.
TUFKAB – the user formerly known as blackbird
Benutzeravatar
jens
Moderator
Beiträge: 8481
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Freitag 6. April 2007, 18:51

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:

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
BlackJack

Freitag 6. April 2007, 18:52

@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!?
Zuletzt geändert von BlackJack am Freitag 6. April 2007, 19:05, insgesamt 1-mal geändert.
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Freitag 6. April 2007, 18:56

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)
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Freitag 6. April 2007, 20:28

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. :-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Freitag 6. April 2007, 22:45

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
My god, it's full of CARs! | Leonidasvoice vs Modvoice
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Samstag 7. April 2007, 00:14

Leonidas hat geschrieben:...Smarty auch ein Templatesystem, welches von der Syntax her ein wenig an das von Django erinnert.
Ich sag nur ptemplates.
TUFKAB – the user formerly known as blackbird
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Samstag 7. April 2007, 09:53

blackbird hat geschrieben:
Leonidas hat geschrieben:...Smarty
ptemplates.
Hi!

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

mfg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Samstag 7. April 2007, 10:58

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
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

Samstag 7. April 2007, 11:02

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