Seite 1 von 1

Django eigene Models + Admin UI

Verfasst: Samstag 18. April 2009, 23:34
von Jan.O
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

Re: Django eigene Models + Admin UI

Verfasst: Sonntag 19. April 2009, 00:42
von Dauerbaustelle
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?

Verfasst: Sonntag 19. April 2009, 01:39
von Jan.O
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 ;)

Verfasst: Sonntag 19. April 2009, 02:24
von Dauerbaustelle
Naja, erbe doch von der User-Klasse... das ist afaik die beste Methode

Verfasst: Sonntag 19. April 2009, 02:25
von Jan.O
Dauerbaustelle hat geschrieben:Naja, erbe doch von der User-Klasse... das ist afaik die beste Methode
Ist im Django-universum echt unschön

Verfasst: Sonntag 19. April 2009, 08:08
von sma
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

Verfasst: Sonntag 19. April 2009, 10:36
von apollo13
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.

Verfasst: Montag 20. April 2009, 15:14
von zwobot
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