Das deutsche Python-Forum

Hallo alle beisammen.

Werkzeug 0.1 rückt immer näher und mit dem ersten Release will ich mal was Neues machen, und zwar komplette Beispielanwendungen beipacken, damit man sieht wie man Probleme lösen kann.

Momentan gibt es ein paar abstrakte, die zeigen wie man sprachspezifische Infos in URLs hinterlegt, eine für Sessions, eine für magische Zusatzfunktionen und dann noch eine richtige, die ein kleines Wiki (Werkzeug + SQLAlchemy + Genshi) implementiert.

Doch gehen mir gerade Ideen für kleine Anwendungen aus, die nicht schwer zu implementieren sind aber ganz gut zeigen, was man mit so einer Library machen kann. Wer also Ideen hat, her damit

Zusätzlich möchte ich die Gelegenheit gleich mal beim Schopf packen und euch fragen was ihr so von Werkzeug bis jetzt hält (vorausgesetzt ihr habt es euch schon angesehen oder werdet es auch bis zum Anworten noch ansehen ^^)

Meine Meinung kennst du ja schon

Ich finde es super weil es nicht auf die anderen Komponenten eingeht wie es bei Pylons der Fall ist, Pylons ist eben ein Framework.

Das Routing hat mich positiv überrascht, auch wenn ich das Regex routing von Django gewöhnt war (Und ich dessen Flexibilität und Einfachheit sehr schätze, ja ich finde den django url dispatcher einfach).

Auch lässt sich durch ein paar shortcuts sehr einfach die Funktionsweise von render_to_response etc. implementieren...

Zum Rest kann ich noch nicht so viel sagen, weil sich das erst zeigen wird, wenn ich es wo für ein Projekt brauche...

Zur Zeit schaut mein Webtoolkit so aus:
-> Django wo's geht (und weiterhin hoffen, dass das orm verbessert wird)
-> Werkzeug für den Rest. Pylons hat sich mit dem Aufkommen von Werkzeug für mich selbst disqualifiziert... (Außerdem weiß ich bei Werkzeug, dass ich nur pidgin öffnen muss und eine kompetente Person zur Hilfe steht

So wie bei Django im Irc *gg*)

EDIT:// Hu du hast ja deinen Namen geändert

apollo13 hat geschrieben:Auch lässt sich durch ein paar shortcuts sehr einfach die Funktionsweise von render_to_response etc. implementieren...

render_to_response habe ich schon mal implementiert. Ich plane das ins `kickstart`-Modul beizeiten mal einzupflegen.

Wie wärs mit einem Wiki? Man kann das ja in `pickle`-Dateien speichern lassen, dann hat man kein SQLAlchemy-Dependency. Oder eine To-Do-Liste, die SQLAlchemy nutzt. Oder etwas was ZODB/Durus nutzt (also auch eine To-Do-Liste oder ähnliches).

Genau, eine ToDo-Anwendung, mit viel JavaScript, und einer dementsprechenden Anwendung für das JavaScript Routing, damit ich auch mal verstehe, wofür das gedacht ist *g*

Auf Allefälle währe eine kleine Anwendung denkenswert, die Werkzeug bestmöglich ausnutzt. Also nicht auf externe Lösungen (Genshi, SQLAlchemy) zurückgreift. Schließlich ist Werkzeug nicht nur aufs Routing begrenzt und bringt neben verschiedenen WSGI-Helferlein auch noch ne kleine eigene Template-Engine mit. Und wenn du in einer Beispielanwendung auch noch das 'kickstart'-modul mit einbeziehst, sehen Einsteiger auch, das sie für ganz kleine Dinge kaum etwas selber machen müssen

MfG EnTeQuAk

Leonidas hat geschrieben:Wie wärs mit einem Wiki? Man kann das ja in `pickle`-Dateien speichern lassen, dann hat man kein SQLAlchemy-Dependency.

Erm. Gibts doch schon

Aber halt mit SQLAlchemy.

Oder eine To-Do-Liste, die SQLAlchemy nutzt. Oder etwas was ZODB/Durus nutzt (also auch eine To-Do-Liste oder ähnliches).

Todo-Liste wäre eine Möglichkeit. Da könnte man sogar CSV oder sowas für nutzen. (Oder XML) Nur ist halt Datei Locking so blöd.

Nochwas zum routing: Regular Expression Routen sind natürlich an Funktionalität nicht zu schlagen. Aber der umgekehrte Weg (bauen nicht matchen) ist mit Reguar-Expressions schwer bis unmöglich. (Wie baut man r"/foo/(.*)(?:\.html)?") Und im Gegensatz zu Werkzeug Routing konvertieren sie auch nicht herum

Dass es Werkzeug 0.1 wirklich gibt, glaube ich erst, wenn's draußen ist

Als weitere Beispielanwendung schlage ich eine Art minimales Newsscript/Gästebuch vor, also etwas, was einfach nur Einträge annimmt und hintereinander ausgibt. Letztlich eine Art TODO-Liste mit mehr Text und ohne Checkboxen

Zuviel Gewicht sollte IMHO aber auch nicht auf Beispielanwendungen liegen, auch wenn ein positiver Effekt oft da ist. Letztlich sollten die Eigenschaften von Werkzeug im Vordergrund stehen, und das kann wohl nur eine gute Dokumentation bewerkstelligen.
Für umfangreichere Anwendungen, die über einfachste Funktionen hinausgehen, wird man sich meist eher mit Template-Engine, Datenbank-Abstraktion und ähnlichem austoben, und dafür sollten andere Websites die Anlaufstellen sein und bleiben.

Ich stopf's einfach mal hier mit rein: Folgt Werkzeugs Routing-Komponente der 'wsgiorg.routing_args'-Spezifikation? Ich würde das sehr begrüßen.

Y0Gi hat geschrieben:Ich stopf's einfach mal hier mit rein: Folgt Werkzeugs Routing-Komponente der 'wsgiorg.routing_args'-Spezifikation? Ich würde das sehr begrüßen.

Nein tut es nicht und wird es auch nicht. Du kannst dir, wenn es dir ein Anlegen ist, die values selber ins environ stopfen, aber ich schließe mich da JPE an: das WSGI Enviornment ist kein Kommunikationskanal für anwendungsinterne Logik wie Sessions, Routing etc.

Werkzeug ist also ein Rahmenwerk zur Webanwendungsentwicklung. Bislang nutze ich Django (Pylons hatte ich mir aufgrund einer Empfehlung eines Kollegen angeschaut, doch das kam mir wie Flickwerk vor; den Konfigurationsaufwand fand ich abschreckend. TurboGears will ja wohl den Pylons-Weg gehen; den Screencast für die 1.0 Version fand ich ebenfalls nicht ansprechend).

In der Feature-Liste von Werkzeug hat mich der Punkt "interaktiver Debugger" die Seite bookmarken lassen - soetwas habe ich bei Django schon vermisst.

Du hast nach Ideen für Beispielanwendungen gefragt. Hier sind ein paar: Blog, Wiki und Todo-Liste sind offensichtlich. Bei einem Blog würde ich gerne eine Artikel-Liste, einen RSS-Feed und vielleicht eine Kommentierfunktion sehen. Der Wiki sollte Seiten anlegen, ändern und rendern können. Die Todo-Liste erfasst Punkte, die man dann später als erledigt markieren kann und bietet die Möglichkeit für Ajax.

Wie wäre es mit einer Soduko-Anwendung? Es wird ein Soduko basierend auf einer Zufallszahl erstellt, auf einer Webseite angezeigt und der User kann die fehlenden Zahlen nachtragen. Das System prüft per Ajax, ob die eingegebenen Zahlen passen. Ist der Soduko-Algorithmus zu aufwendig, ginge auch Tic-Tac-Toe oder Reversi.

Eine Variante eines Wikis ist, wenn ich zwei URLs habe, über die ich entweder eine Seite zum Ändern eines Dokuments bekomme oder eine Seite, die das Dokument anzeigt. Wer die erste (nicht ratbare) URL kennt, kann das Dokument bearbeiten. Alle anderen können nur lesen. Dies erlaubt gemeinsam bearbeitbare Dokumente im Web ohne komplizierte User-Verwaltung.

Auch ein einfaches Diskussionsforum ist letzlich eine Variante des Blog/Wiki-Themas. Spannend finde ich hier die Frage, wie man pro Anwender ungelesene Beiträge speichern kann.

Ich glaube, bei Lisp-basierten Webrahmenwerken ist es Pflicht, einen Reddit-Clone zu bauen. Das könntest du auch machen. Links können gepostet und bewertet werden. Optional könnte man Links Kommentieren, doch das überlappt sich mit dem Blog bzw. der Forums-Idee.

http://djangogigs.com will zwischen Entwicklern und Projekten vermitteln. Das System ist recht einfach, wirkt aber dennoch nützlich auf mich. Projekte und Entwickler können angemeldet und durchsucht werden. Man beachte, dass sich die Entwickler für einen Ansatz entschieden haben, der keine Anmeldung erfordert.

Eine Umfrage-Webseite wie das Django-Tutorial baut, wäre ebenfalls ein recht einfaches Beispiel. Als kleinen Twist würde ich mir wünschen, derartige Umfragen mit Hilfe eines JavaScripts in eigene Anwendungen einbetten zu können.

Twitter nachbauen ist glaube ich ebenfalls guter Stil bei Webrahmenwerken. Wohl an, das Datenmodell besteht aus Status-Updates, Usern und Freundschaftsbeziehungen, die Anzeige entspricht im Prinzip der eines Blogs.

Irgendwo hatte ich neulich so eine Wiedervorlage-Webanwendung gesehen, bei der man Webseiten registieren konnte (von denen dann ein Screenshot gemacht wurde) und sagen konnte, man wolle sie sich "demnächst" nochmal wieder anschauen. Der Server erinnert dann.

Ein MUD (um man wieder etwas spielerisches zu erwähnen) mit Web-UI fände ich auch interessant, befürchte aber, dass der Webspezifische Code neben dem Code für das Spiel selbst untergehen könnte. Ich bräuchte Personen, untereinander verbundene Räume und Gegenstände. Interessant wäre, wie man eine an sich zustandslose Weboberfläche mit einem inherent zustandsbehafteten MUD-Server kombinieren kann. Neue Nachrichten per Ajax vom Server zu pollen scheint da fast schon trivial. Zwei Leute, die gegeneinander Schach (oder Schiffe versenken, wenn's noch einfacher sein soll) spielen können, böte eine einfachere Grundlage für das Problem, einen persistenten Server per Backend anzusprechen.

Stefan

sma hat geschrieben:In der Feature-Liste von Werkzeug hat mich der Punkt "interaktiver Debugger" die Seite bookmarken lassen - soetwas habe ich bei Django schon vermisst.

So etwas hat mitsuhiko schon für Django geschrieben, siehe die entsprechende Diskussion auf django-developers in der das abgelehnt wurde.

Leonidas hat geschrieben:[Einen interaktiven debugger] hat mitsuhiko schon für Django geschrieben

Super! Werde morgen dann mal schauen, ob der patch sich auf den aktuellen trunk anwenden lässt. Das ist jetzt sicherlich OT, aber mir kommt es vor, als wenn die Django-Entwickler öfter mal interessante Vorschläge recht ruppig ablehnen und dann lagern sie irgendwo in Trac...

sma hat geschrieben:
Leonidas hat geschrieben:[Einen interaktiven debugger] hat mitsuhiko schon für Django geschrieben
Super! Werde morgen dann mal schauen, ob der patch sich auf den aktuellen trunk anwenden lässt. Das ist jetzt sicherlich OT, aber mir kommt es vor, als wenn die Django-Entwickler öfter mal interessante Vorschläge recht ruppig ablehnen und dann lagern sie irgendwo in Trac...

In diesem Fall wars wohl eher nen security Grund, und das auch erst nach längerer Diskussion iirc.

sma hat geschrieben:Werkzeug ist also ein Rahmenwerk zur Webanwendungsentwicklung. Bislang nutze ich Django (Pylons hatte ich mir aufgrund einer Empfehlung eines Kollegen angeschaut, doch das kam mir wie Flickwerk vor; den Konfigurationsaufwand fand ich abschreckend. TurboGears will ja wohl den Pylons-Weg gehen; den Screencast für die 1.0 Version fand ich ebenfalls nicht ansprechend).

Werkzeug ist nicht wirklich ein Framework. Es kommt ohne Datenbank, Template Engine (nicht *ganz* wahr) und anderen Utilities. Ist daher allerdings auch kein Flickwerk, zumindest darfst du dir selber aussuchen, was du einbaust um auf Datenbanken etc. zuzugreifen.
Wenn du volle Flexibilität willst, ist Werkzeug was für dich, ansonsten eher django oder Pylons.

In der Feature-Liste von Werkzeug hat mich der Punkt "interaktiver Debugger" die Seite bookmarken lassen - soetwas habe ich bei Django schon vermisst.

Siehe Leonidas.

Du hast nach Ideen für Beispielanwendungen gefragt. Hier sind ein paar: Blog, Wiki und Todo-Liste sind offensichtlich. Bei einem Blog würde ich gerne eine Artikel-Liste, einen RSS-Feed und vielleicht eine Kommentierfunktion sehen. Der Wiki sollte Seiten anlegen, ändern und rendern können. Die Todo-Liste erfasst Punkte, die man dann später als erledigt markieren kann und bietet die Möglichkeit für Ajax.

Blog gibts schon TextPress, das sollte irgendwann um Weihnachten mal ein Release bekommen, kann ich aber noch nicht versprechen und kleines Wiki gibts im example Ordner.

Wie wäre es mit einer Soduko-Anwendung? Es wird ein Soduko basierend auf einer Zufallszahl erstellt, auf einer Webseite angezeigt und der User kann die fehlenden Zahlen nachtragen. Das System prüft per Ajax, ob die eingegebenen Zahlen passen. Ist der Soduko-Algorithmus zu aufwendig, ginge auch Tic-Tac-Toe oder Reversi.

Sudoku wäre für AJAX wirklich eine Idee. Merk ich mir.

Eine Variante eines Wikis ist, wenn ich zwei URLs habe, über die ich entweder eine Seite zum Ändern eines Dokuments bekomme oder eine Seite, die das Dokument anzeigt. Wer die erste (nicht ratbare) URL kennt, kann das Dokument bearbeiten. Alle anderen können nur lesen. Dies erlaubt gemeinsam bearbeitbare Dokumente im Web ohne komplizierte User-Verwaltung.

Zu komplex für eine kleine Beispielanwendung

Auch ein einfaches Diskussionsforum ist letzlich eine Variante des Blog/Wiki-Themas. Spannend finde ich hier die Frage, wie man pro Anwender ungelesene Beiträge speichern kann.

<xorAxAx>pocoo ist tot</xorAxAx>

Ich glaube, bei Lisp-basierten Webrahmenwerken ist es Pflicht, einen Reddit-Clone zu bauen. Das könntest du auch machen. Links können gepostet und bewertet werden. Optional könnte man Links Kommentieren, doch das überlappt sich mit dem Blog bzw. der Forums-Idee.

Ich wollte eigentlich cmlenz' Geddit portieren, aber da waren mir zu wenig Framework Logik drin.

mitsuhiko schrieb "Werkzeug ist nicht wirklich ein Framework." und ich muss ihm recht geben, schon daher, da es nicht dem "don't call us, we call you" Prinzip genügt, sondern eher eine Sammlung von wiederverwendbaren Hilfsfunktionen ist, also eine klassische Bibliothek. Mein Fehler. Und nicht schlimm für das Projekt - im Gegenteil.

Der Vorteil ist größere Flexibilität. Der Nachteil ist IMHO, dass sowas die Anwendergruppe stärker zersplittern kann. (Meine persönliche Theorie ist, das Ruby mit Rails gegenüber Python in der Frage der Aufmerksamkeit deshalb gewonnen hat, weil hier die Anwendergemeinschaft relativ geschlossen hinter einem Rahmenwerk steht, während bei Python (genau wie bei Java, wo man auch 30+ verschiedene Rahmenwerke findet) bestimmt ein Dutzend Lösungen existiert, die um Aufmerksamkeit buhlen - doch das ist ein anderes Thema).

Wenn man drei OR-Mapper, zwei Dispatcher und vier Template-Engines (a la Pylon) kombinieren kann, hat man eigentlich 24 verschiedene Rahmenwerke und die Gefahr, dass sich die Anwendergruppe selbst verfleischt.

Mit dem (sicher etwas negativ belasteten) Wort Flickwerk wollte ich gerade auf diese notwendige Auswahl anspielen. Statt selbst eine Meinung zu haben, überlässt der Autor des Rahmenwerks oder der Bibliothek es dem Anwender. Ich bin offensichtlich jemand, der diese Flexibiltät nicht zu schätzen weiß

Von dem eigenen mitgelieferten Template-System abzuraten wirkt daher auf mich komisch. Ich habe noch nicht so ganz durchschaut, (ob und) wie die im Rahmen von pocoo gehosteten Lösungen zusammenspielen, doch ich hätte vielleicht einen Verweis auf Jinja oder sogar eine feste Integration erwartet.

Das es TextPress gibt, hatte ich schon gesehen, doch du hast nach kleinen Beispielen - vielleicht hin Form von Tutorials, das wäre mein Favorit für eine Präsentationsform - für Werkzeug gefragt.

Was ich mir da vorstelle ist ein System, welches die Essenz eines Blogs abbildet, sodass man lernen kann, wie du dir vorstellst, dass man Werkzeug nutzen soll. Ungefähr den Funktionsumfang, den man in einem 20 minütigen Video zeigen kann, wenn man schnell tippt und ab und zu "oops" ruft

Beantworten sollte der Code IMHO auch die Frage, warum ein Blog basierend auf Werkzeug nun besser ist als ein Blog basierend auf Django, Pylons oder wie sie alle heißen.

Du dem "writeboard"-Clone sagst du zu komplex, doch was ich mir vorstellte wäre deutlich einfacher als dein existierendes Wiki-Beispiel, das du "klein" nennst.

Du hast eine Startseite, die dir erklärt, worum es geht und einen Knopf hat, mit dem du ein neues Dokument erstellen kannst. Vielleicht hat die Startseite auch noch eine Liste (und einen RSS-Feed) mit den aktuellsten Dokumenten, die als öffentlich markiert wurden - muss aber nicht. Auf der neuen Seite kann man das Dokument bearbeiten - für die Demo reicht Text oder markdown, optional mit einem Preview (inline wie z.B. hier, klassischer Serverroundtripp ist aber auch okay). Auf der Seite sieht man zwei URLs zum kopieren: Die aktuelle URL zum Bearbeiten und die URL für 's reine Anzeigen.

Datenmodell wäre IMHO (in Django-Sprech):

Code: Alles auswählen

class Document(models.Model):
  view_id = models.CharField(max_length=20, primary_key=True)
  edit_id = models.CharField(max_length=20, unique=True)
  created_at = models.DateTimeField()
  updated_at = models.DateTimeField()
  title = models.CharField(max_length=200)
  text = models.TextField()
  text_html = models.TextField()

Stefan

sma hat geschrieben:Der Nachteil ist IMHO, dass sowas die Anwendergruppe stärker zersplittern kann. (Meine persönliche Theorie ist, das Ruby mit Rails gegenüber Python in der Frage der Aufmerksamkeit deshalb gewonnen hat, weil hier die Anwendergemeinschaft relativ geschlossen hinter einem Rahmenwerk steht, während bei Python (genau wie bei Java, wo man auch 30+ verschiedene Rahmenwerke findet) bestimmt ein Dutzend Lösungen existiert, die um Aufmerksamkeit buhlen - doch das ist ein anderes Thema).

Da hast du ganz recht - die Theorie vertrete ich auch, wenn man zugeben muss dass die Beschaffenheit von Ruby als Rails-Unterbau da auch eine Rolle spielen. Nicht zu vergessen gibt es auch zahlreiche weitere Frameworks für Ruby, die teilweise wie schon Nitro länger als Rails existieren. Einige davon gehen sogar in Richtungen die Python-Frameworks auch einschlagen. Inzwischen ist aber auch in der Python-Welt nach der log-Phase die stationäre Phase eingetreten, bis hin zur Absterbephase (Subway gibt es nicht mehr, pythonweb auch nicht, SQLObject wurde an den Rand gedrängt, TG wird eher zu "Pylons mit bestimmten Komponenten", Colubrid wird obsolete). Ich denke interessante Zeiten stehen bevor, während deren sich die besten Frameworks herauskristallisieren und teilweise auch neue entstehen, die interessante, neue Wegen gehen (Grok etwa).

sma hat geschrieben:Wenn man drei OR-Mapper, zwei Dispatcher und vier Template-Engines (a la Pylon) kombinieren kann, hat man eigentlich 24 verschiedene Rahmenwerke und die Gefahr, dass sich die Anwendergruppe selbst verfleischt.

Richtig. In der Realität nimmt am aber oft das was Empfohlen wird, etwa SQLAlchemy, Mako, den eingebauten Dispatcher, fertig. TG zielt ja scheinbar genau darauf ab, ein "Set" von Tools zu sein, die gut zusammenarbeiten sollen. Natürlich - es ist ein Problem, dass man besonders als Anfänger nicht weiß wo man anfangen soll. Ich habe aber auch das Gefühl, dass solche Frameworks auch gar nicht auf Anfänger abzielen sondern auf Leute die genau wissen was sie wollen.

sma hat geschrieben:Mit dem (sicher etwas negativ belasteten) Wort Flickwerk wollte ich gerade auf diese notwendige Auswahl anspielen. Statt selbst eine Meinung zu haben, überlässt der Autor des Rahmenwerks oder der Bibliothek es dem Anwender. Ich bin offensichtlich jemand, der diese Flexibiltät nicht zu schätzen weiß

Auch für dich gibt es Frameworks - Django eben. Dort hast du recht wenig Wahl, außer du hast Spaß die ausgetretenen Pfade zu verlassen. Aber dann kannst du oftmals auch gleich ein anderes Framework verwenden eben weil die Django-Komponenten so gut miteinander funktionieren.

sma hat geschrieben:ich hätte vielleicht einen Verweis auf Jinja oder sogar eine feste Integration erwartet.

Eine Integration ist für Kickstart geplant. Ich nutze selbst Jinja in dem Projekt aus dem Kickstart entstanden ist (kann dich beruhigen, Jinja spielt sehr gut mit Werkzeug zusammen). Wird also sicherlich kommen. Nur eben nicht als Kern-Komponente, was ich auch gut finde.

Ian Bicking bezeichnet Paste als "Metaframework". Generell ist eine Namensfindung nicht so einfach. Für mich sind Paste und Werkzeug das, was ihren Kern darstellt und sie für mich interessant macht: WSGI-Implementierungen, die mir die Schnittstelle in Form von hübschen Request- und Response-Objekten anbieten. Der Rest ist, für diesen Layer, nur Zubehör - der nicht zu Unrecht auch ausgelagert wird (s. WebOb, werkzeug.contrib), allerdings auch meist zu trivial für ein eigenes Paket ist.

"Framework" geht als Begriff schon Richtung Buzzword, da es *sehr* vieles Bedeuten kann und (entsprechend des Wortes an sich) kaum genau definiert ist. Im Web-Applikationsbereich sind Frameworks meiner Erfahrung nach in der Regel Vorselektionen und Integration von Komponenten für einzelne Aufgaben.

Was die Debugging-Middleware von Werkzeug angeht: Lässt die sich nicht einfach in Django "einschieben"? Es ist schließlich eine WSGI-Middleware. Ich nutze sie selbst auch in Projekten, die nicht auf Werkzeug aufsetzen.

Y0Gi hat geschrieben:Was die Debugging-Middleware von Werkzeug angeht: Lässt die sich nicht einfach in Django "einschieben"? Es ist schließlich eine WSGI-Middleware. Ich nutze sie selbst auch in Projekten, die nicht auf Werkzeug aufsetzen.

An sich: ja. Jedoch sind Django-Middlewares nicht WSGI-Middlewares. Du kannst also einen WSGI-Traceback einschieben, aber die Idee war ja, den Prompt in den bereits existierenden, recht hübschen Traceback einzubauen.

Jep, ein Traceback Debugger wurde aber werden sicherheits Bedenken nicht realisiert, siehe: http://code.djangoproject.com/ticket/3527

Das ganze als Django-Middleware zu realisieren wäre doch eigentlich schön...

Das deutsche Python-Forum

Kleine Web-Beispielanwendungen

Kleine Web-Beispielanwendungen