Django eigene Models + Admin UI

Sockets, TCP/IP, (XML-)RPC und ähnliche Themen gehören in dieses Forum
Jan.O
User
Beiträge: 61
Registriert: Samstag 26. April 2008, 00:32

Django eigene Models + Admin UI

Beitragvon Jan.O » Samstag 18. April 2009, 23:34

Hi,

ich bin ganz neu dabei, mich mit django zu beschäftigen. Mir gefällt das system der models sehr gut, und ich würde gerne auch die User-Models selber definieren, da das user-model nicht alle eigenschaften besitzt welche ich brauche. Jedoch scheine ich einige Apps zwangsläufig einbinden zu müssen, wenn ich das automatische admin interface benutzen möchte.

Standartmäßig sind ja die folgenden Apps eingebunden:

Code: Alles auswählen

    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',


Sollte ich die alle drin lassen? Wäre es eine unsaubere herangehensweise, jetzt einfach noch eine weiter userklasse neben django.contrib.auth zu programmieren?

Danke!
Jan
Dauerbaustelle
User
Beiträge: 996
Registriert: Mittwoch 9. Januar 2008, 13:48

Re: Django eigene Models + Admin UI

Beitragvon Dauerbaustelle » Sonntag 19. April 2009, 00:42

Jan.O hat geschrieben:Sollte ich die alle drin lassen?

Wenn du das Admininterface nutzen willst, ja.
Jan.O hat geschrieben:Wäre es eine unsaubere herangehensweise, jetzt einfach noch eine weiter userklasse neben django.contrib.auth zu programmieren?

`django.contrib.auth` ist ein Modul und warum sollte es unsauber sein, eigene Module/Klassen zu schreiben?
Jan.O
User
Beiträge: 61
Registriert: Samstag 26. April 2008, 00:32

Beitragvon Jan.O » Sonntag 19. April 2009, 01:39

Weil sich das Auth modul User-Modelle enthält, welche sich nicht ändern lassen. Somit müsste ich also noch mal ein user modell machen, was man als unsauber betrachten könnte. Gibt es da vielleicht ein sauberes workaround?

Jan

PS: Ich hoffe sauberes workaround schließt sich nicht aus ;)
Dauerbaustelle
User
Beiträge: 996
Registriert: Mittwoch 9. Januar 2008, 13:48

Beitragvon Dauerbaustelle » Sonntag 19. April 2009, 02:24

Naja, erbe doch von der User-Klasse... das ist afaik die beste Methode
Jan.O
User
Beiträge: 61
Registriert: Samstag 26. April 2008, 00:32

Beitragvon Jan.O » Sonntag 19. April 2009, 02:25

Dauerbaustelle hat geschrieben:Naja, erbe doch von der User-Klasse... das ist afaik die beste Methode


Ist im Django-universum echt unschön
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Beitragvon sma » Sonntag 19. April 2009, 08:08

Ja, contrib.admin hängt leider von contrib.auth ab. Die Abhängigkeit von contrib.session finde ich nicht so schlimm. Als ich das letzte mal guckte, konnte man contrib.sites auch weglassen. Ich habe mal versucht, ein anders (mandantenfähiges) User-Objekt zu konstruieren, aber ohne entweder massiv Code für den User zu kopieren bzw. zu verändern oder große Teile des Admin-UIs neu zu bauen, gibt es da keinen Weg. Das Problem wird auch nur noch schlimmer, wenn du 3rd-Party-Code einsetzen willst. Der bezieht sich eigentlich immer auf das vorhandene User-Objekt.

Wenn du nur einige neue Attribute haben willst (und keine 3rd-Party-Komponente das ebenfalls versucht), kannst du wie in http://docs.djangoproject.com/en/dev/to ... bout-users beschrieben vorgehen.

Die andere Alternative ist eine Unterklasse, doch auch dafür musst du einiges ändern, denn das auth-backend denkt nicht im Traum daran, deine Unterklasse zu erzeugen, sondern erzeugt immer "echte" User (siehe z.B. auth/backends.py, Zeile 18). Ich hatte mir damit beholfen, mein User-Objekt (welches von dem Original erbte) danach in "contrib.auth.models.User" hinein-zu-monkey-patchen.

Stefan
apollo13
User
Beiträge: 827
Registriert: Samstag 5. Februar 2005, 17:53

Beitragvon apollo13 » Sonntag 19. April 2009, 10:36

sma hat geschrieben:Ja, contrib.admin hängt leider von contrib.auth ab. Die Abhängigkeit von contrib.session finde ich nicht so schlimm.

Wird hoffentlich besser, wenn das UserObject abstrakt wird (1.2 vlt ;))

Die andere Alternative ist eine Unterklasse, doch auch dafür musst du einiges ändern, denn das auth-backend denkt nicht im Traum daran, deine Unterklasse zu erzeugen, sondern erzeugt immer "echte" User (siehe z.B. auth/backends.py, Zeile 18). Ich hatte mir damit beholfen, mein User-Objekt (welches von dem Original erbte) danach in "contrib.auth.models.User" hinein-zu-monkey-patchen.

Würg, kotz kotz. Es zwingt dich keiner das ModelBackend zu verwenden, das kannst du austauschen und in deinem eigenen ein kompatibles User Objekt returnen; mit etwas Arbeit bekommt man so auch ein Mandatenfähigessystem hin.
zwobot
User
Beiträge: 2
Registriert: Freitag 2. Februar 2007, 20:51

Beitragvon zwobot » Montag 20. April 2009, 15:14

Eine weitere Möglichkeit ist ein Userprofil zu verwenden, welches auch die empfohlene und unterstützte Vorgehensweise in der Doku ist, um zusätzliche Informationen/Attribute zu einem User zu speichern:

http://docs.djangoproject.com/en/dev/to ... bout-users

Du musst hierbei nicht die django.contrib.auth.models (das ist das was du wahrscheinlich nicht willst) und und Django unstützt diese Userprofile durch spezielle Methoden.

Gruss
Zwobot

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder