Django eigene Models + Admin UI

[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

[Dauerbaustelle]

Sollte ich die alle drin lassen?

Wenn du das Admininterface nutzen willst, ja.

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]

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]

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

[Jan.O]

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

Ist im Django-universum echt unschön

[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

[apollo13]

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]

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