Hi Jacob, Thanks for taking the time to tackle this issue!
On Tue, Apr 3, 2012 at 2:35 AM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote: > Hi folks -- > > I've written up a proposal for how *I* would like to address refactoring > auth.user: https://gist.github.com/2245327. > > In essence, this does two things: > > * Vastly "prunes" the required fields on auth.user. The only things left are > an "identifier" (which could be username, email, url, uuid, whatever), and a > password. > * Introduces a new "profile" system that provides a way to contribute extra > related fields. Multiple profiles are supported, along with some syntactic > sugar for dealing with multiple profiles in a reasonably reusable way. I very much like the idea of stripping down the user fields. I am currently using an approach that's very similar to your proposal in all my projects, except that instead of creating several profiles, I directly add fields to the User model using this snippet: https://gist.github.com/1283969 (I am not the initial author) With this, adding a field to the user model is as simple as: class MyUser(models.Model): newsletter = models.BooleanField() class Meta: abstract = True contribute_to_model(MyUser, User) I already use this to patch the email field in the User model or make group names not unique for instance. The only issue is that the contributed models need to be registered as early as possible. Currently I import them in my urls.py, but we can imagine adding hooks for such things that need to be done at startup time (app-refactor? :) or use your AUTH_PROFILES setting for this (not enthusiastic about this one). I am fully aware that this can be abused a lot. However this makes a couple of things simpler: * No need to proxy fields on the User model, it stays a normal model with no special treatment * Conflicts are simply resolved: if two models contribute the same field, the last one registered wins * No need for a special-cased form for editing profile-related fields, a simple ModelForm with includes = ['fields', 'to', 'include'] works. This is the technique I will use anyway if your proposal is implemented, and I don't see anything that would prevent this from working with the new auth so I'm mainly posting this because I haven't seen this approach in the different proposals for the auth refactor. -Bruno -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
