Das deutsche Python-Forum

@jens
Ich werds mir mal angucken. Wie gesagt, ich beschäftige mich erst seit kurzem mit Python, habe aber das Gefühl, dass die Sprache durch Ihre Flexibilität wirklich gut für ein absolut veränderbares System eignet. Mal gucken, wie gut ich mich zurechtfinde

Ich kenne Django noch überhaupt nicht, was für eine Art von DB-Abstraktion bietet das? Wie gesagt, von klassischen Abstraktionsschichten, die auf (vereinfachtes) Inline-SQL setzen, würde ich gerne verzichten und alle Daten Objekt-Relational mappen.

Wie auch immer, im minimalen Grundsystem und dem Grundsatz "alles ist ein Plugin" stimmen wir wohl überein

@Leonidas
Wie gesagt, ich bin da im Moment am zweifeln. Wie gesagt, ich arbeite im Moment hauptsächlich mit Typo3. Dort ist das wenigste per klassischem Template zu bearbeiten.
Allerdings gibt es per TypoScript die möglichkeit fast alles anzupassen. TS allerdings ist eine Sache, die ich nicht als Vorbild nehmen möchte. Alles was konfigurierbar ist, sollte das meines Erachtens auch mitteilen, so dass automatisch eine entsprechende Oberfläche zur Verfügung gestellt wird.
Meine Gedanken gehen ein wenig in die Richtung, dass man statt mit Templates auf eine Art semantische Controls setzen kann.
Aber vermutlich ist ein relativ mächtiger Output-Prozessor (dann wirklich in der Art von Smarty, aber wohl etwas abgespeckt) doch sinnvoll.

dst hat geschrieben:@jens
Ich kenne Django noch überhaupt nicht, was für eine Art von DB-Abstraktion bietet das? Wie gesagt, von klassischen Abstraktionsschichten, die auf (vereinfachtes) Inline-SQL setzen, würde ich gerne verzichten und alle Daten Objekt-Relational mappen.

Django kommt mit einem OR Mapper. Das kuhle daran ist das er nicht aus der DB zur Laufzeit "Models Generiert" wie Rails, sondern aus den Models die Datenbank generiert

Hat zwar beides Vor und Nachteile, mir gefällt Djangos Ansatz jedoch bisher klar besser.

Jens hat geschrieben: Wozu? Dann nimmt man einfach SQLite. Bei Django's DB-Abstraktionsschicht müsste man normalerweise nichts anpassen Wink

Gut... mag sein

--> Aber ich mag halt immer Lösungen, die möglichst portabel sind und sagen wir ma... keine Installationen voraussetzen. Klar ist das optional... währe aber noch etwas, was man mit einbauen könnte. (aber nicht muss)

MfG EnTeQuAk

@veers
Das klingt doch ganz nett.
Ich denke, dass der andere Weg (Models anhand einer Datenbankstruktur generieren) in unserem Fall überhaupt nicht passen würde.
Inwiefern lassen sich die Models denn "im laufenden Betrieb" ändern? Sprich, wenn ich z.B. eine Extension installiere, die ein zusätzliches Feld in Usertabelle braucht, lässt sich das mit vertretbarem Aufwand realisieren?

@entequak
SQLite erfordert keine Installation sondern arbeitet von Haus aus mit simplen Dateien. Natürlich müssen die entsprechenden "Treiber" für Python vorliegen, aber das müssen sie ja ohnehin.

dst hat geschrieben:Inwiefern lassen sich die Models denn "im laufenden Betrieb" ändern? Sprich, wenn ich z.B. eine Extension installiere, die ein zusätzliches Feld in Usertabelle braucht, lässt sich das mit vertretbarem Aufwand realisieren?

Weitere Tabellen anlegen ist kein Problem. Dafür gibt es syncdb: http://www.djangoproject.com/documentat ... in/#syncdb

Existierende Tabellen ändern geht allerdings nicht out-of-the-box. Es gibt keine Routine dafür. Man muß also selber zusehen, das man die Tabellen aktualisiert.
IMHO ist das aber auch nicht so das Problem. Ich lege PyLucid immer eine Update Routine dabei: http://pylucid.net/trac/browser/trunk/P ... _Update.py (Das ist für die v0.7, die nicht django Version)
Wenn man allerdings verschiedene DBs unterstützten möchte, muß man die Update-Routine für jede einzelne DB anpassen, weil IMHO die ALTER TABLE Syntax nicht 100% gleich ist.
Eine andere Möglichkeit ist es die Tabellen zu löschen und neu erstellen zu lassen, aber das ist ja nicht wirklich ein Update

SQLite erfordert keine Installation sondern arbeitet von Haus aus mit simplen Dateien. Natürlich müssen die entsprechenden "Treiber" für Python vorliegen, aber das müssen sie ja ohnehin.

Nicht? --> Dann hab ich bisher immer falsch gedacht. Also ich habe es immer (auf meinem Ubuntu) installiert. Obs ohne ging, hab ich nie ausprobiert.

hmm...

MfG EnTeQuAk

SQLite ist ab Python 2.5 direkt mit dabei... Für alle älteren Versionen muß man es nachinstallieren

Siehe: http://docs.python.org/whatsnew/modules ... 0000000000

veers hat geschrieben:Django kommt mit einem OR Mapper. Das kuhle daran ist das er nicht aus der DB zur Laufzeit "Models Generiert" wie Rails, sondern aus den Models die Datenbank generiert

Stimmt nicht ganz - auch in Rails musst du Scaffolding nicht nutzen - du kannst deine Modelle ebenso wie in den Python ORMs deklarieren.

Leonidas hat geschrieben:Stimmt nicht ganz - auch in Rails musst du Scaffolding nicht nutzen - du kannst deine Modelle ebenso wie in den Python ORMs deklarieren.

Hm, aber Rails kann afaik nicht aus einem Model eine Datenbank erstellen...

dst hat geschrieben:@veers
Das klingt doch ganz nett.
Ich denke, dass der andere Weg (Models anhand einer Datenbankstruktur generieren) in unserem Fall überhaupt nicht passen würde.
Inwiefern lassen sich die Models denn "im laufenden Betrieb" ändern? Sprich, wenn ich z.B. eine Extension installiere, die ein zusätzliches Feld in Usertabelle braucht, lässt sich das mit vertretbarem Aufwand realisieren?

Nunja für den Fall gibts es die Möglichkeit erweiterte User Attribute zu definieren

Ansonsten ist es vermutlich sinnvoller neue Felder Explizit anzulegen.

btw. so sieht es z.Z. aus mit PyLucid in der django Version: pylucid.de
Aber da ist noch viel Arbeit zu machen, wie man sehen kann

Einen _install Bereich gibt es auch wieder: pylucid.de/_install/XXX/ Da wo XXX ist, bitte als Passwort 12345678 eintragen

Die ganz Artigen dürfen sich auch im django Admin einloggen. Der Username ist test und das Passwort das selbe, wie für die _install-Sektion

Login Link ist ja auf der Seite selber...

jens hat geschrieben: Existierende Tabellen ändern geht allerdings nicht out-of-the-box. Es gibt keine Routine dafür. Man muß also selber zusehen, das man die Tabellen aktualisiert.
IMHO ist das aber auch nicht so das Problem.

Und das ist auch gut so, wenn ich nur daran denke, dass mir jemand meine Daten zerstört durch nen blödes Update!

jens hat geschrieben:btw. so sieht es z.Z. aus mit PyLucid in der django Version: pylucid.de
Aber da ist noch viel Arbeit zu machen, wie man sehen kann

Einen _install Bereich gibt es auch wieder: pylucid.de/_install/XXX/ Da wo XXX ist, bitte als Passwort 12345678 eintragen
Die ganz Artigen dürfen sich auch im django Admin einloggen. Der Username ist test und das Passwort das selbe, wie für die _install-Sektion Login Link ist ja auf der Seite selber...

WTF? Wie hast du den admin umgeschrieben?
Hat der in den Templates nicht /admin/ Verweise drin, wie bringst du _admin zum funktionieren?

EDIT:
Sowas wie:

Code: Alles auswählen

 15     def __str__(self):
 16         return self.titel

wäre in den Modelklassen sehr hilfreich, dann steht nimmer "group object" sondern eben self.titel dort, ist sehr angenehm

apollo13 hat geschrieben:WTF? Wie hast du den admin umgeschrieben?
Hat der in den Templates nicht /admin/ Verweise drin, wie bringst du _admin zum funktionieren?

Einfach den view an die URL binden, fertig. Siehe:
http://pylucid.net/trac/browser/branche ... py?rev=886

__str__ Hab ich oft überschrieben, aber noch nicht immer. Generell muß ich die Modelle noch ein wenig für die Admin Seiten anpassen, siehe:
http://pylucid.net/trac/browser/branche ... py?rev=886

jens hat geschrieben:
apollo13 hat geschrieben:WTF? Wie hast du den admin umgeschrieben?
Hat der in den Templates nicht /admin/ Verweise drin, wie bringst du _admin zum funktionieren?
Einfach den view an die URL binden, fertig. Siehe:
http://pylucid.net/trac/browser/branche ... py?rev=886

Hab ich dann auch gesehen, interessant ist nur, dass sie nirgendwo auf /admin/ referenzieren (in links etc...). Eben schön programmiert

Jetzt weiß ich was du meinst... Es scheint egal zu sein, an welcher URL man den Admin Bereich klatscht. Alle URLs innterhalb des Admin Bereiches scheinen relativ zu sein

Das einzige was man machen muß ist den ADMIN_MEDIA_PREFIX richtig setzten, damit die CSS und JS Dateien gefunden werden.

jens hat geschrieben:Jetzt weiß ich was du meinst... Es scheint egal zu sein, an welcher URL man den Admin Bereich klatscht. Alle URLs innterhalb des Admin Bereiches scheinen relativ zu sein
Das einzige was man machen muß ist den ADMIN_MEDIA_PREFIX richtig setzten, damit die CSS und JS Dateien gefunden werden.

Stimmt, nur bei den meisten Anwendungen ist das leider nicht so. Aber mit dem Url-tag wird es sicher besser

apollo13 hat geschrieben:Aber mit dem Url-tag wird es sicher besser

URL-Tag?

Ich habe ja meinen eigenen URL-Tag geschrieben aber vermute dass es da noch etwas besseres gibt. Werde ich bei Gelegenheit genauer untersuchen müssen.

Ja, es gibt einen URL tag um auf views zu verweisen: http://www.python-forum.de/post-59886.html#59886

Das deutsche Python-Forum

CMS Schreiben