Seite 1 von 2
Meine ersten Schritte mit Karrigell
Verfasst: Freitag 26. Januar 2007, 01:54
von gerold
Hi!
Ich musste einfach mal ein paar Dinge bei Karrigell ausprobieren...
Diese pih-Dateien (Python in HTML) fühlen sich wie die alten ASP-Dateien (Active Server Page) an. Funktioniert sehr gut, aber ASP wurde viel zu schnell komplex und so sieht es wahrscheinlich auch mit diesen pih-Dateien aus. Hier müsste man gleich von Anfang an auf eine gute Vorlagensprache ausweichen. Z.B. TAL, KID, oder so etwas. Ich werde das später mal mit SimpleTal ausprobieren.
my_form.pih:
Code: Alles auswählen
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<title>Mein Formular</title>
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
</head>
<body>
<%
# Variablen
error_message = locals().get("error_message", "")
name = locals().get("name", "")
# Fehlermeldung anzeigen
%>
<% if error_message: %>
<div style="border-color: red; border-style: solid; margin: 0.5em;">
<%= error_message %>
</div>
<% end %>
<% # Formular %>
<form action="my_handler.py">
Name: <input type="text" name="name" value="<%= name %>" /><br />
<input type="submit" value="Submit" />
</form>
</body>
</html>
Code: Alles auswählen
import Template
name = QUERY.get("name", None)
if name == "Gerold":
# Meldung anzeigen
my_answer = Template.getScript("my_answer.pih")
print my_answer.render(name = name).value
else:
# my_form.pih wieder aufrufen und Fehler anzeigen
error_answer = Template.getScript("my_form.pih")
print error_answer.render(
name = name, error_message = "Gib 'Gerold' ein..."
).value
lg
Gerold
Verfasst: Freitag 26. Januar 2007, 17:13
von Leonidas
Was mich jetzt auch interessieren würde, wäre der Vergleich mit Spyce. Seit 2.0 ist das ja unter neuer Leitung und wird schneller weiterentwickelt (verglichem mit Spyce 1.4.x) (außerdem liest man auf DPU öfters was von Jonathan Ellis).
Spyce konnte man (in alten Tagen) relativ problemlos mit Cheetah-Templates versehen, aber damals gab es auch wesentlich weniger Templatesysteme.
Re: Meine ersten Schritte mit Karrigell
Verfasst: Freitag 26. Januar 2007, 19:42
von gerold
gerold hat geschrieben:Hier müsste man gleich von Anfang an auf eine gute Vorlagensprache ausweichen. Z.B. TAL, KID, oder so etwas. Ich werde das später mal mit SimpleTal ausprobieren.
Hi!
So weit bin ich zwar noch nicht, aber zumindest habe ich schon mal den Einstiegspunkt gefunden.
Es gibt im Karrigell-Ordner einen Ordner mit dem Namen ``modules``. In diesem wird nach Python-Modulen gesucht, die mit ``mod_`` beginnen und auf ``.py`` enden. Wenn ich möchte, dass die Dateien mit der Endung ``.tal`` von Karrigell interpretiert werden, dann muss ich nur in diesem Ordner ein Python-Modul mit dem Namen ``mod_tal.py`` anlegen. Schon werden alle TAL-Dateien von diesem Modul interpretiert. Das ist also der Einstiegspunkt, an dem ich später ansetzen werde...
lg
Gerold
PS: Die Vorlagensprache
Cheetah ist bereits in Carrigell integriert.
Verfasst: Samstag 24. Februar 2007, 21:58
von nkoehring
Hallo... ich habe jetzt nach meinen vielen Kaempfen mit mod_python auch mal Karrigell ausprobiert und ich bin absolut begeistert
Ich bin ja nicht so der Fan von PHP-artigem Scripting und hab von daher auch alles was ich brauche... eine index.py und einen Printbefehl
Ich finde es so genial einfach. Wenn ich bedenke wie kompliziert das alles mit mod_python ist. Hier in Karrigell gebe ich einfach alles nach
stdout aus und es ist gut. Ich werd am Montag gleich mal zum Admin rennen und ihm das aufschwatzen ...ich bin mit ihm per Du ...also denk ich, wird das nicht das Problem sein. Es muss halt nur unter Solaris laufen (Karrigell ist doch sicherlich reines Python, oder hat jemand schonmal negatives darueber gehoert, ob es auf Solaris laeuft?).
Verfasst: Sonntag 25. Februar 2007, 00:39
von gerold
Hi!
Ich habe auch schon TAL/METAL integriert. Es ist zwar noch nicht perfekt, da man die Pfade zu den METAL-Vorlagen noch "händisch" angeben muss, aber imerhin.
Leider konnte ich noch nicht viel Zeit in "TAL/METAL mit Karrigell" investieren. Aber was ich so gelesen habe, ist die Vorlagensprache Cheetah auch nicht so ohne. Man kann die einzelnen Vorlagen wie Klassen beerben und Definitionen überschreiben. Damit hat man ein einfaches System für die Aufarbeitung, von sich wiederholenden Inhalten.
Sobald ich eine Schnittstelle zu einer Kaffemaschine und noch ein paar Kundenwünsche programmiert habe, werde ich ein paar Tage frei nehmen und in die etwas bessere Integration von TAL und METAL in Karrigell investieren. Eine Dokumentation muss dann auch noch geschrieben werden, damit es auch von anderen benutzt werden kann. Und idealerweise wäre da noch meine geliebte "Acquisition", damit über Pfadvererbung auf Objekte zugegriffen werden kann. --> Zope for ordinary people...
lg
Gerold
Verfasst: Montag 26. Februar 2007, 07:35
von mitsuhiko
Wenn endlich alle Frameworks WSGI reden kommt wieder einen, dass das nicht tut. War irgendwie absehbar
Verfasst: Montag 26. Februar 2007, 08:01
von gerold
blackbird hat geschrieben:Wenn endlich alle Frameworks WSGI reden kommt wieder einen, dass das nicht tut. War irgendwie absehbar
Der Preis für WSGI ist derzeit viel zu hoch!
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.
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.
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!
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.
Warum willst du jemandem WSGI einreden, wenn es die Arbeit im Moment nur verkompliziert, verlängert und
nur den Pseudo-Vorteil der Wahlmöglichkeit der Schnittstelle (mod_python, fastcgi,...) bringt? Das verstehe ich nicht.
Verfasst: Montag 26. Februar 2007, 08:16
von gerold
...habe ich schon erwähnt, dass man statische Inhalte wie Bilder oder reine HTML-Seiten einfach nur in den ``webapps``-Ordner speichert und Karrigell diese
ohne zusätzliche Konfiguration ausliefert?
Verfasst: Montag 26. Februar 2007, 09:02
von jens
gerold hat geschrieben:Das Karrigell-Tar-Archiv entpackt man irgendwohin, startet ``karrigell.py`` und schon läuft der eingebaute (recht schnelle) Webserver.
Das ist schön, machen aber alle anderen Frameworks meist auch.
Aber was machst du im Shared-Webhosting bereicht, wo du keinen Shell Zugang hast? Wie funktioniert Karrigell da?
Verfasst: Montag 26. Februar 2007, 09:19
von gerold
jens hat geschrieben:Aber was machst du im Shared-Webhosting bereicht, wo du keinen Shell Zugang hast? Wie funktioniert Karrigell da?
Hi Jens!
Mit
mod_rewrite:
http://karrigell.sourceforge.net/en/apache.htm
Aber in diese Lage werde ich nie kommen, da wir für unsere Firma jetzt schon zwei Webserver laufen haben.
Und für die, die nicht in so einer glücklichen Lage sind. Es gibt günstige vHosts und bei gpcom.de gibt es um 8,- Euro mod_rewrite und Python im "Web Private SH M"-Paket.
Edit: Da fällt mir noch ein: wenn irgendjemand Karrigell über WSGI ausführen möchte, dann glaube ich nicht, dass das mit so großen Schwierigkeiten machbar ist. Karrigell ist reines Python und ziemlich einfach gebaut. Es muss nur jemand machen.
Verfasst: Montag 26. Februar 2007, 11:55
von BlackJack
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.
Verfasst: Montag 26. Februar 2007, 18:26
von Leonidas
gerold hat geschrieben:Es gibt günstige vHosts und bei gpcom.de gibt es um 8,- Euro mod_rewrite und Python im "Web Private SH M"-Paket.
Die Firma hat aber nichts mit dir zu tun, oder?
Verfasst: Montag 26. Februar 2007, 18:51
von gerold
Leonidas hat geschrieben:gerold hat geschrieben:gpcom.de
Die Firma hat aber nichts mit dir zu tun, oder?
Hi Leonidas!
Ich hatte mal die Domäne "gpcom.at", aber das ist schon lange her. Mit "gpcom.de" habe ich leider nichts zu tun.
lg
Gerold
Verfasst: Donnerstag 1. März 2007, 14:21
von Y0Gi
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.
Für den Endkunden ist es insofern interessant, als dass er eine Vielzahl von Deployment-Möglichkeiten hat und nicht auf mod_python, CGI oder sonstwas beschränkt ist.
Verfasst: Freitag 30. März 2007, 07:57
von gerold
Dieser Link zum Thema "Karrigell" dürfte interessant sein:
http://www.devshed.com/c/a/Python/Karrigell-for-Python/
lg
Gerold
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!
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.