On Apr 5, 11:29 pm, Tai Lee <[email protected]> wrote: > But I still don't see how a swapped in `User` model which *has* to behave in > a specified way so that it can work with the Django admin and any other > pluggable apps that might have special requirements, is any better than > simply allowing the admin and other pluggable apps to have their profile and > authentication needs self-contained? > > If Django's `User` model was just a stub (without even username and password > fields), and Django shipped with an abstract `BaseAuth` model with a > `username` field that was email compliant and a `password` field, and > corresponding `BaseAuthForm` and `BaseAuthBackend`, then user's can still > create their own `User` model with literally *whatever* fields they want in > it, they can use the standard auth fields, form and backend provided by > Django, or roll their own. > > Instead of creating a custom `User` model that quacks like an admin duck, and > quacks like every pluggable app that is installed as well, all they need to > do is create/update an an `AdminUser` whenever their custom `User` is saved. > > This is explicit, the admin and other pluggable apps know where to access > information that they need (from their own models), and the developer has > control over how the data is kept in sync across the pluggable apps used in > the project, at the project level.
If every application provides a profile which matches it needs, you will get a serious case of data-duplication. Every application which needs email-address should then create a profile containing the email. Another way to solve this would be to check the existing profiles for the email field, and now you have introduced some magic, and in addition you have mostly just moved the interface contract from the User model to its profile. So, you have the same problem again. This is the failing of the profile based approach: you don't actually solve anything by it, you just move the problem around (and introduce more problems by doing that). (Yes, I was +1 on the idea. Opinions change...) I guess 90% of users will either use the BackwardsCompatibilityUser, or the new shiny FixedUser. For most users they are more than adequate. The issue is only when you really need something completely different for one reason or another. In addition with proxy models and custom managers you can have pretty good profile based approach in the cases where you need it. It is a good approach if you have TwitterUser, FaceBookUser, GooglePlusUser and so on. (Or CustomerUser, EmployeeUser and so on). I bet one of the hardest problems will be how to define the ORM interface, and how custom classes can fulfill that. .filter(is_admin=True) can only work if there is a is_admin field. I guess everything will need to go through manager methods, and the "must implement" set must be kept at minimum. - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
