@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.
CMS Schreiben
- veers
- User
- Beiträge: 1219
- Registriert: Mittwoch 28. Februar 2007, 20:01
- Wohnort: Zürich (CH)
- Kontaktdaten:
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.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.
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)Jens hat geschrieben: Wozu? Dann nimmt man einfach SQLite. Bei Django's DB-Abstraktionsschicht müsste man normalerweise nichts anpassen Wink
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.
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.
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Weitere Tabellen anlegen ist kein Problem. Dafür gibt es syncdb: http://www.djangoproject.com/documentat ... in/#syncdbdst 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?
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
Nicht? --> Dann hab ich bisher immer falsch gedacht. Also ich habe es immer (auf meinem Ubuntu) installiert. Obs ohne ging, hab ich nie ausprobiert.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.
hmm...
MfG EnTeQuAk
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
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
Siehe: http://docs.python.org/whatsnew/modules ... 0000000000
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Stimmt nicht ganz - auch in Rails musst du Scaffolding nicht nutzen - du kannst deine Modelle ebenso wie in den Python ORMs deklarieren.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
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
- veers
- User
- Beiträge: 1219
- Registriert: Mittwoch 28. Februar 2007, 20:01
- Wohnort: Zürich (CH)
- Kontaktdaten:
Hm, aber Rails kann afaik nicht aus einem Model eine Datenbank erstellen...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.
Nunja für den Fall gibts es die Möglichkeit erweiterte User Attribute zu definieren Ansonsten ist es vermutlich sinnvoller neue Felder Explizit anzulegen.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?
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
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...
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...
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: 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.
WTF? Wie hast du den admin umgeschrieben?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...
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
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Einfach den view an die URL binden, fertig. Siehe: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?
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
Hab ich dann auch gesehen, interessant ist nur, dass sie nirgendwo auf /admin/ referenzieren (in links etc...). Eben schön programmiertjens hat geschrieben:Einfach den view an die URL binden, fertig. Siehe: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?
http://pylucid.net/trac/browser/branche ... py?rev=886
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
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.
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 besserjens 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.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
URL-Tag?apollo13 hat geschrieben:Aber mit dem Url-tag wird es sicher besser
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.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Ja, es gibt einen URL tag um auf views zu verweisen: http://www.python-forum.de/post-59886.html#59886