Erfahrungsbericht: Pylons und Mako
Verfasst: Samstag 11. August 2007, 20:07
Servus,
Ich habe heute endlich angefangen mir Pylons mal genauer anzusehen, d.h. genauer als nur die Webseite durchzulesen, sondern es auch tatsächlich einzusetzen.
Da dachte ich mir, dass ich passend zum Erfahrungsbericht: CherryPy und Cheetah einen analogen Erfahrungsbericht zu schreiben.
Also los:
Die Instalation
Die Installation von Pylons (0.9.6rc2) geht problemlos, benutzt setuptools und installiert unglaublich viele Eggs. Ein Problem war, dass das aktuelle stabile Release 0.9.5 ist und gewisse Änderungen in 0.9.6 eingeflossen sind, so dass ich nicht wusste, welche ich hätte nehmen sollen. Ich tippe aber, dass ich mit dem Release Candidate wohl die bessere Wahl getroffen habe. Dazu habe ich noch Elixir von easy_install installieren lassen, welches SQLAlchemy mitgezogen hat.
Informationen gibt es auf der Pylons-Seite in akzeptabler Quantität, empfehlenswert ist das Getting Started Dokument. SQLAlchemy hat auch viel Dokumentation, Elixir hingegen leider sehr wenig, d.h. fast keine brauchbare. Das Wiki ist in der Pylons-Seite ganz grauenhaft eingebunden und irritiert jedes mal, erinnert an TG - in Django sieht das wesentlich konsistenter aus und die Informationen sind leider teilweise auf die Versionen 0.9.5 und 0.9.6 verteilt. Aber das wird sich wohl bald nach dem Release von 0.9.6 ändern.
Wenn man außerhalb der Pylons Seite nach Informationen sucht, findet man noch zwei Screencasts. Der erste ist totale Zeitverschwendung, da wird nur gezeigt wie man Python installiert, Komodo Edit installiert und wie TortoiseSVN nutzt. Der andere ist etwas besser - man lernt dabei zwar nicht so viel, aber man bekommt zumindest einen groben Überblick über Pylons. Das Getting Started Dokument ist danach eine brauchbare Lektüre. Außerdem findet man noch einiges an CherryPy-Bashing (unprofessionelle Entwicklungsmethode, Bugs), aber ob das auch CP 3 betrifft weiß ich nicht. Dann findet man auch noch ein paar Notizen warum Mako besser als Cheetah ist (besseres Caching, mehr Features).
Was ich bisher von Routes gesehen habe wirft mich nicht aus den Schuhen, denn ich finde den Django-Delegator mit dessen Regular Expressions ziemlich brauchbar. Mal sehen ob Routes irgendeinen Interessanten Mehrwert bietet oder ob ich mir nicht noch selector ansehe.
Ich wollte eigentlich auch noch tesla einsetzen (um Elixir hübsch in Paste einzubinden), aber das zieht noch vielmehr Eggs mit und einige von den Projekten sind inzwischen unmaintained. Mal sehen wie sich das entwickelt.
Von der Qualität von Mako bin ich auch noch nicht ganz überzeugt, d.h. ich bin nicht sicher ob es mir gefällt, Python-Code ins Template zu tun. Auch das mysteriöse ``c``-Objekt finde ich eher seltsam. Da scheint mir die Context-Behandlung in Django expliziter und klarer zu sein. Im 2. Screencast sieht man, dass man in Mako auch Templatevererbung hat und dort über Python-Code so etwas wie Blöcke hinbekommt.
Die Datenbank, Teil 1 + Support
Pylons setzt keinerlei ORM vorraus, Pylons ist es völlig egal woher die Daten kommen. Das geht sogar so weit, dass Pylons schlcihtweg kein ORM mitbringt. Die meisten nutzen jedoch das bekannte SQLAlchemy ein. Da SQLAlchemy im vergleich mit ORMs wie SQLObject oder Storm etwas "eigen" ist, nutzen einige auch noch den Wrapper Elixir der es ermöglicht, die Datenbankmodelle etwas deklarativer zu definieren (ist übrigens aus TurboENtity und ActiveMapper hervorgegangen). So wie SQLAlchemy eine sehr umfassende und brauchbare und, ja, auch bitter nötige Dokumentation hat, so finde ich die Dokumentation zu Elixir etwas spärlich. Viele Objekte kommen aus SQLAlchemy, also muss man immer zwei Dokumentationen konsultieren.
Letztendlich habe ich mich aber gegen Elixir entschieden, denn so sehr interessierte mich das dann doch nicht und dachte mir, dass ich erstmal mich in SQLAlchemy einarbeite. Am glecihen Tag wie ich das gemacht habe, wurde SQLAlchemy 0.4.0beta1 fertig und mir wurde empfohlen, gleich das einzusetzen. Nun warte ich auf ein 0.4 Release der Hilfsbibliothek SAContext - gut dass ich diese Woche nicht da bin, vielleicht passiert ja etwas in der Woche.
Bin auch schon in meine ersten Probleme reingeraten, als ich das Dokument SQLAlchemy for people in a hurry durchgearbeitet habe. Diese wurden mithilfe der Leute aus #pylons gelöst, der Pylons-Entwickler benbangert (aka Ben Bangert) war selbst anwesend und hat mir einige Tipps gegeben. Ebenso hat mir zzzeek (aka Mike Bayer), der SQLAlchemy entwickelt geholfen einen Fehler in ebendiesem Dokument aufzudecken und mir einige Fragen bezüglich der Typen erklärt.
Der Support auf #django ist dank Leuten wie Magus- gut, aber das die Entwicker dort online sind ist selten. Daher finde ich es überaus positiv, dass die Entwickler von Pylons und SQLAlchemy so leicht erreichbar sind.
Bisher habe ich es leider noch nicht geschafft meine Daten aus der alten Datenbank in eine SQLAlchemy Datenbank zu migrieren, was aber teilweise auch daran liegt, dass ich unglaublich viel drumrum erst noch erkunden musste.
Edit: Zweiten Abschnitt geschrieben.
Ich habe heute endlich angefangen mir Pylons mal genauer anzusehen, d.h. genauer als nur die Webseite durchzulesen, sondern es auch tatsächlich einzusetzen.
Da dachte ich mir, dass ich passend zum Erfahrungsbericht: CherryPy und Cheetah einen analogen Erfahrungsbericht zu schreiben.
Also los:
Die Instalation
Die Installation von Pylons (0.9.6rc2) geht problemlos, benutzt setuptools und installiert unglaublich viele Eggs. Ein Problem war, dass das aktuelle stabile Release 0.9.5 ist und gewisse Änderungen in 0.9.6 eingeflossen sind, so dass ich nicht wusste, welche ich hätte nehmen sollen. Ich tippe aber, dass ich mit dem Release Candidate wohl die bessere Wahl getroffen habe. Dazu habe ich noch Elixir von easy_install installieren lassen, welches SQLAlchemy mitgezogen hat.
Informationen gibt es auf der Pylons-Seite in akzeptabler Quantität, empfehlenswert ist das Getting Started Dokument. SQLAlchemy hat auch viel Dokumentation, Elixir hingegen leider sehr wenig, d.h. fast keine brauchbare. Das Wiki ist in der Pylons-Seite ganz grauenhaft eingebunden und irritiert jedes mal, erinnert an TG - in Django sieht das wesentlich konsistenter aus und die Informationen sind leider teilweise auf die Versionen 0.9.5 und 0.9.6 verteilt. Aber das wird sich wohl bald nach dem Release von 0.9.6 ändern.
Wenn man außerhalb der Pylons Seite nach Informationen sucht, findet man noch zwei Screencasts. Der erste ist totale Zeitverschwendung, da wird nur gezeigt wie man Python installiert, Komodo Edit installiert und wie TortoiseSVN nutzt. Der andere ist etwas besser - man lernt dabei zwar nicht so viel, aber man bekommt zumindest einen groben Überblick über Pylons. Das Getting Started Dokument ist danach eine brauchbare Lektüre. Außerdem findet man noch einiges an CherryPy-Bashing (unprofessionelle Entwicklungsmethode, Bugs), aber ob das auch CP 3 betrifft weiß ich nicht. Dann findet man auch noch ein paar Notizen warum Mako besser als Cheetah ist (besseres Caching, mehr Features).
Was ich bisher von Routes gesehen habe wirft mich nicht aus den Schuhen, denn ich finde den Django-Delegator mit dessen Regular Expressions ziemlich brauchbar. Mal sehen ob Routes irgendeinen Interessanten Mehrwert bietet oder ob ich mir nicht noch selector ansehe.
Ich wollte eigentlich auch noch tesla einsetzen (um Elixir hübsch in Paste einzubinden), aber das zieht noch vielmehr Eggs mit und einige von den Projekten sind inzwischen unmaintained. Mal sehen wie sich das entwickelt.
Von der Qualität von Mako bin ich auch noch nicht ganz überzeugt, d.h. ich bin nicht sicher ob es mir gefällt, Python-Code ins Template zu tun. Auch das mysteriöse ``c``-Objekt finde ich eher seltsam. Da scheint mir die Context-Behandlung in Django expliziter und klarer zu sein. Im 2. Screencast sieht man, dass man in Mako auch Templatevererbung hat und dort über Python-Code so etwas wie Blöcke hinbekommt.
Die Datenbank, Teil 1 + Support
Pylons setzt keinerlei ORM vorraus, Pylons ist es völlig egal woher die Daten kommen. Das geht sogar so weit, dass Pylons schlcihtweg kein ORM mitbringt. Die meisten nutzen jedoch das bekannte SQLAlchemy ein. Da SQLAlchemy im vergleich mit ORMs wie SQLObject oder Storm etwas "eigen" ist, nutzen einige auch noch den Wrapper Elixir der es ermöglicht, die Datenbankmodelle etwas deklarativer zu definieren (ist übrigens aus TurboENtity und ActiveMapper hervorgegangen). So wie SQLAlchemy eine sehr umfassende und brauchbare und, ja, auch bitter nötige Dokumentation hat, so finde ich die Dokumentation zu Elixir etwas spärlich. Viele Objekte kommen aus SQLAlchemy, also muss man immer zwei Dokumentationen konsultieren.
Letztendlich habe ich mich aber gegen Elixir entschieden, denn so sehr interessierte mich das dann doch nicht und dachte mir, dass ich erstmal mich in SQLAlchemy einarbeite. Am glecihen Tag wie ich das gemacht habe, wurde SQLAlchemy 0.4.0beta1 fertig und mir wurde empfohlen, gleich das einzusetzen. Nun warte ich auf ein 0.4 Release der Hilfsbibliothek SAContext - gut dass ich diese Woche nicht da bin, vielleicht passiert ja etwas in der Woche.
Bin auch schon in meine ersten Probleme reingeraten, als ich das Dokument SQLAlchemy for people in a hurry durchgearbeitet habe. Diese wurden mithilfe der Leute aus #pylons gelöst, der Pylons-Entwickler benbangert (aka Ben Bangert) war selbst anwesend und hat mir einige Tipps gegeben. Ebenso hat mir zzzeek (aka Mike Bayer), der SQLAlchemy entwickelt geholfen einen Fehler in ebendiesem Dokument aufzudecken und mir einige Fragen bezüglich der Typen erklärt.
Der Support auf #django ist dank Leuten wie Magus- gut, aber das die Entwicker dort online sind ist selten. Daher finde ich es überaus positiv, dass die Entwickler von Pylons und SQLAlchemy so leicht erreichbar sind.
Bisher habe ich es leider noch nicht geschafft meine Daten aus der alten Datenbank in eine SQLAlchemy Datenbank zu migrieren, was aber teilweise auch daran liegt, dass ich unglaublich viel drumrum erst noch erkunden musste.
Edit: Zweiten Abschnitt geschrieben.