Bericht über Python Web Development

[ms4py]

Hallo,
ich will an der Hochschule einen Bericht über Python Web Development schreiben. Suche Vorschläge für weitere Themen, die abzudecken sind, und/oder Krititk an meiner bisherigen Gliederung.
Ganz grob habe ich mir diese so vorgestellt:

- Überblick
Kurze Vorstellung der mögl. Technologien (CGI und WSGI); evt. Statistiken etc.; Übersicht über bekannte Seiten, die Python verwenden (hier bräuchte ich noch Ideen...)

- WSGI
* Einführung
* kleine WSGI App from scratch, vermutlich nur "hello world" o.ä.

- Frameworks
* django
* (was soll ich noch vorstellen? zope/plone?)
* ..
* bottle

- Google App Engine
* Erklärung
* "Hello World"

- Praxisbeispiel
Kleines Projekt mit bottle und google, evt. "Movielibrary" oder so etwas in diese Richtung.

Edit: Ein Wiki wäre evt. auch ein nettes Projekt. Gibt es für irgendein Wiki-Markup schon ein Parser in Python?

Edit2: Titel angepasst.

[jbs]

Edit: Ein Wiki wäre evt. auch ein nettes Projekt. Gibt es für irgendein Wiki-Markup schon ein Parser in Python?

Wie wäre es mit markdown?

[lunar]

Oder auch ReStructuredText.

[BlackJack]

Bekannte Webseiten: SourceForge und YouTube.

Rahmenwerke: TurboGears 1+2, Pylons, vielleicht noch Glashammer

Wo würden CherryPy oder Werkzeug reinpassen!?

Gegenfrage gibt's ein WikiMarkup für dass es noch keinen Parser gibt?

MoinMoin und Trac sind verbreitete Wikis in Python.

[Mr_Snede]

Als Markup mag ich creole, das ist eine eingängiges Subset aus verbreiteten Markuplanguages.

PyPI Suche

... und werlcher Jens hat da seine Spuren hinterlassen??
Python lib 'python-creole'

Ich fände ein Wiki Beispiel auch klasse . Speziell, wenn es seinen eigenen "Server" mitbringt. (jaja purer Eigennutz)
Stelle mich als Tester zur Verfügung

Gruß Sebastian

[jens]

... und werlcher Jens hat da seine Spuren hinterlassen??
Python lib 'python-creole'

Das bin ich
Auch hier zu finden:
http://pypi.python.org/pypi/python-creole/
http://code.google.com/p/python-creole/

[sma]

Wenn du ein "full stack web framework" zeigen willst, halte ich einen Wiki für kein gutes Beispiel, da es hier ausreicht, Dateien einzulesen und formatiert anzuzeigen. Selbst wenn man eine Wikiseiten durch eine Klasse repräsentieren will: Da hat man dann ein Attribut "text". Vielleicht noch einen Autor oder Titel, aber das war's dann schon.

Da Sinatra gerade 1.0 geworden ist (und ich dir die Python-Variante überlassen möchte), hier eine Skizze, wie ein Wiki funktionieren kann:

Code: Alles auswählen

get "/:name" do |n|
  "<h1>#{n}</h1>#{format(read(n))}"
end

get "/:name/edit" do |n|
  "<h1>Edit #{n}</h1><form ... #{read(n)} ... form>"
end

post "/:name" do |n|
  write(n, params[:text])
  redirect "/#{n}"
end

Die Helper `read`, `write` und `format` sind aus Web-Rahmenwerk-Sicht schon wieder egal.

Ein interessantes minimales Datenmodell ist IMHO ein Blog mit Kommentaren und Kategorien. Beiträge haben eine 1:n Relation zu Kommentaren und eine n:m Relation zu Kategorien. Optional könnte ich noch per 1:1 Relation ein Bild an den Beitrag hängen. Dann habe ich alle Arten der Relationen abgedeckt und kann demonstrieren, wie das von verschiedenen Rahmenwerken abgedeckt wird, wie einfach es ist, eine Admin-Oberfläche zu bauen usw.

URL-technisch ist natürlich auch dieses Beispiel nicht anspruchsvoll. Aber man kann nicht alles haben. Hier mehr zu machen bedeutet IMHO, gleich ein komplexeres Beispiel anzugehen. Spannend fände ich, RESTful URLs zu diskutieren. Welches Rahmenwerk hilft hier wie viel. IMHO ist Rails hier ein gutes Vorbild, das es zu erreichen gilt.

Schließlich könnte man das Deployment diskutieren. Wie aufwendig ist es, die App zum Laufen zu bringen. Hier lassen sich Vorteile und Nachteile der GAE beleuchten. Oder wieder ein Vergleich mit Ruby, wo Heroku es erlaubt, mit einem "git push" seine Anwendung zu deployen. Einfacher habe ich's bislang noch nirgendwo gesehen.

Stefan

[ms4py]

Wenn du ein "full stack web framework" zeigen willst, halte ich einen Wiki für kein gutes Beispiel, da es hier ausreicht, Dateien einzulesen und formatiert anzuzeigen. Selbst wenn man eine Wikiseiten durch eine Klasse repräsentieren will: Da hat man dann ein Attribut "text". Vielleicht noch einen Autor oder Titel, aber das war's dann schon.

Mit einer Changeset/History-Funktion und Tags komme ich durchaus auf ein Datenmodell mit 1:n und m:n Beziehungen
Deine weiteren Anregungen sind aber durchaus interessant!

[philistion]

Ich würde unbedingt die Unterschiede zu Rails herausstreichen und ohne zu werten Stärken und Schwächen von RoR im Vergleich zu diversen Python-Frameworks darstellen.

[Hyperion]

Ich würde unbedingt die Unterschiede zu Rails herausstreichen und ohne zu werten Stärken und Schwächen von RoR im Vergleich zu diversen Python-Frameworks darstellen.

Wozu? Laut ms4py geht es nur darum, Konzepte für das Webdevelopment mit Python vorzustellen... wozu dann also ein Vergleich, der zudem recht einseitig ist?

[BlackJack]

Vor allem müsste man dann RoR auch noch kennen/können. Und müsste man dann nicht der Vollständigkeit halber auch Webentwicklung mit J2EE in den Vergleich einbeziehen? Wo soll das enden?

[nemomuk]

PHP / Perl / ...

Definitiv nicht Umfang der Arbeit. Ich würde eine kleine Bottle-Sample WikiApp vorschlagen. Vllt. wäre auch noch ganz interessant, wie man solche Apps dann im Produktiv-System einsetzt (Apache, Nginx, lighttp, fpws,...).

[ms4py]

Wiki >> http://gbottle-wiki.appspot.com/
Repo >> http://bitbucket.org/ms4py/gbottle-wiki/

[ms4py]

Ich würde mich gerne noch mit der Portabilität von Webapps für GAE beschäftigen.

Für Java gibt es dafür den BDBdatastore http://arachnid.github.com/bdbdatastore/.
Gibt es etwas in diese Richtung für Python, also ein Layer über dem GAE datastore, das mit mehreren DBs kompatibel ist?

Alternativ habe ich gesehen, dass web2py mit GAE kompatibel ist. Gibt es weitere Frameworks, die mit GAE kompatibel sind?

(Django ist ja ohne ORM dabei, zählt deshalb nicht)

Edit: Ist es usable, den ORM von web2py in einer bottle app zu verwenden? (Vermutlich muss ich das selber testen, oder? Wäre aber auch ein schöner Abschnitt in meiner Arbeit )

[ms4py]

Hallo,
ich bin jetzt fast soweit mit dem Bericht. Hier mein vorläufiges Inhaltsverzeichnis.

1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 WSGI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Spezifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Deploy einer WSGI Applikation . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Komponenten/Funktionalitäten eines Web-Frameworks . . . . . . . . . . . . . . 6
3.2 Klassizierung von Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3 Full-Stack Beispiel - django . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4 Minimalistic Beispiel - bottle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4 Entwicklung eines Wiki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1 Anwendungsfälle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2 Datenbankentwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3 Datenbankmodell mit Elixir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4 Implementierung der wichtigsten Anwendungsfälle . . . . . . . . . . . . . . . . 10
4.5 Authentifikation mit bottle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.6 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.7 Portabilität zu django . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5 Fazit

Der Wiki-Teil ist soweit schon ausgearbeitet, wäre schön, wenn der ein oder andere sich das Ganze kurz durchschauen könnte (vor allem auf technische Aspekte bezogen, Rechtschreibung etc. wird noch extra korrigiert). http://ms4py.org/document.pdf
Die anderen Abschnitte kommen demnächst. (Dienstag ist Abgabe, dauert also nicht mehr lange...)

[BlackJack]

@ms4py: Zeile 5 von `wikipage()` könnte Probleme haben wenn `page_name` etwas ausserhalb von ASCII enthält, oder kommt `bottle.redirect()` damit klar?

Was wird in Anhang A gezeigt? Die Struktur von erm2py geparst? Das was erm2py parst und so im Speicher hält? Das Ergebnis von erm2py? Da wären IMHO ein paar mehr Worte als die Überschrift schön.

[snafu]

Ich würde Django und Bottle mit großem Anfangsbuchstaben schreiben. Der Trennstrich unter 1.2 bei pa-ge ist weder schön, noch grammatikalisch korrektes Englisch. Und wenn wir schon in dem Abschnitt sind: Es heißt Modelling (vgl. String Formatting). Auch würde ich persönlich weniger Anglizismen benutzen - Deploy -> Entwicklung, Use Cases -> Anwendungsfälle, usw. Zudem stolpere ich über deine Relativierungen, die du an mehreren Stellen machst. Dabei redest du dir irgendwie den ganzen Text weich. Entweder du begründest sie oder du lässt sie ganz weg, aber nicht: "Ich binde experimentelle Software ein, auch wenn man das normalerweise nicht tun sollte." Naja, mag sein, dass ich etwas streng bin und deinem Dozenten/Lehrer das alles relativ egal ist.

[ms4py]

Ich würde Django und Bottle mit großem Anfangsbuchstaben schreiben. Der Trennstrich unter 1.2 bei pa-ge ist weder schön, noch grammatikalisch korrektes Englisch. Und wenn wir schon in dem Abschnitt sind: Es heißt Modelling (vgl. String Formatting).

Das dt. Wort "Page" ist so korrekt getrennt LaTeX macht das automatisch, und deutsch ist eben eingestellt. Danke für den Hinweis, werde das korrigieren.

Auch würde ich persönlich weniger Anglizismen benutzen - Deploy -> Entwicklung, Use Cases -> Anwendungsfälle, usw.

Deploy beziehe ich auf das Ausliefern der Applikation mit einem Server. Wikipedia nennt das "Softwareverteilung". Hört sich IMO etwas seltsam an. Aber da gehe ich trotzdem noch einmal darüber. (Wobei mein Prof da vermutlich kein Problem damit hat.)

Zudem stolpere ich über deine Relativierungen, die du an mehreren Stellen machst. Dabei redest du dir irgendwie den ganzen Text weich. Entweder du begründest sie oder du lässt sie ganz weg, aber nicht: "Ich binde experimentelle Software ein, auch wenn man das normalerweise nicht tun sollte." Naja, mag sein, dass ich etwas streng bin und deinem Dozenten/Lehrer das alles relativ egal ist.

Ich habe kein Problem mit strenger Kritik Welche Stellen kommen noch so schwammig rüber?

@BlackJack:
Danke. Werde ich korrigieren.

[ms4py]

Hier Teil 2 über WSGI und Frameworks:
http://ms4py.org/document2.pdf

Wäre schön, wenn jemand das Dokument bis morgen Abend durchschauen könnte. (Da ist Abgabe.)

Selbstverständlich sind letztendlich beide Teile in einem Bericht und ich stelle diesen dann auch zur Verfügung.

[BlackJack]

@ms4py: Beim "Hallo Welt"-Beispiel als Klasse steht dass es etwas komplexer ist, aber die Vorteile der Objektorientierung bietet. Da sollte man IMHO näher drauf eingehen was die Vorteile sind. Ich meine jetzt ausser das Java-Jünger glücklich sind, wenn sie etwas in eine Klasse stecken können.

`Middleware` würde ich entweder an der Stelle erklären wo der Begriff das erste mal vorkommt, oder dort auf den Abschnitt mit dem Titel verweisen. Bei der Abbildung gibt's IMHO bessere Möglichkeiten. In der Django-Doku gibt's irgendwo ein Bild wo statt des Servers links "Request" und rechts "Response" steht und ein Pfeil durch die "Zwiebeldarstellung" der Schichten von einem zum anderen läuft. Das macht deutlicher das es sich aus Sicht der Anwendung eigentlich um "aroundware" handelt, also die Daten beim Eingang wie auch beim Ausgang durch die Middleware laufen. Wenn man mehr als eine Middleware in dem Bild zeigt wird ausserdem deutlich wie die Reihenfolge der Verarbeitung ist, wenn man mehrere Middlewares kombiniert.

Beim `Capitalizer` sehe ich übrigens den Sinn einer Klasse nicht. Den hätte man Problemlos als Funktion implementieren können.

Der erste Absatz zu CherryPy sollte dringend überarbeitet werden. Das liest sich als wenn man unter Windows keine Webserver laufen lassen kann.

Es werden eine Menge "Füllworte" verwendet. Geh da noch mal durch und schau ob man "Eigentlich", "selbstverständlich", "typisch", "auch" usw. wirklich an jeder Stelle braucht, oder ob der Sinn der Sätze ohne diese "schwammigen" Worte nicht genauso erhalten bleibt. Zum Beispiel "Selbstverständlich antwortet eine Webapplikation auch auf Anfragen…". Ist das selbstverständlich? Wenn nein warum nicht, wenn ja, muss das Wort da wirklich stehen? Und warum "auch"? Was tut sie sonst noch? Ist das nicht eine der Hauptaufgaben? In nächsten Absatz mit den Requests und Responses bist Du IMHO ungenau mit Klassen und Exemplaren davon. Das Rahmenwerk stellt Klassen zur Verfügung, die Applikation *verarbeitet* die aber nicht.

Abschnitt `Scaffolding`: Vielleicht besser "Testdatenbestände" statt "Testbestände".

Ich weiss das ist jetzt nicht inhaltlich, aber warum sind `URL-Routing` und `Template-Engine` im `Bottle`-Abschnitt fett gesetzt? Damit stechen die unheimlich ins Auge und fallen aus dem Rahmen.

Und noch eine technische Frage zu `erm2py`/`elixir`: Warum wird die `__str__()`-Methode überschrieben und nicht die `__repr__()? Das was da zurückgegeben wird ist IMHO eher was für Programmierer als für Endanwender!? Und ist das so viel besser als die normale `__repr__()` auf die `__str__()` ja zurückfällt wenn's nicht überschrieben wurde!? Also muss man da überhaupt was überschreiben? Was ist der Vorteil von *dieser* Lösung?