On Tue, Apr 3, 2012 at 9:28 AM, Alex Ogier <alex.og...@gmail.com> wrote: > I have written up a little bit about the alternate proposal that I made a > while ago, Solution 2a > from https://code.djangoproject.com/wiki/ContribAuthImprovements
I just now got around to reading Jacob's solution and Alex's solution. Thanks to everybody for the thoughts and impassioned debate so far. Here's my take on it. First, some background: I haven't used the built-in User module in several years. I always write my own User model from scratch -- it's so nice and clean. Want a twitter_username field? Just add it. No need to add a convoluted foreign key or (oh god) one-to-one relationship to some other table. To me, this is the Right Way to do things. The framework should bend to my needs, I shouldn't bend to the framework's needs. Also, profile modules need to die. They needed to die circa 2006. So, with that in mind, I've got to say I prefer Alex's solution. I really think the right way to do it is: 1. Let you create your own User model, with whichever fields you want. 2. Provide a way to tell Django which model you're using for that. 3. In your own code, just deal with that model like you deal with any other one. No need to jump through hoops. 4. Third-party models should be changed to use something like "user = UserField()", which would automatically create a foreign key to the registered User model. If you change your registered User model after you've created those third-party tables, you're in for trouble. Don't do that. 5. Django provides some generic APIs for getting at the registered user. Example: a middleware that sets request.user based on the current session. 6. Given that some third-party apps will likely want to get access to common attributes of a User -- notably, email address -- there could be some sort of standard interface that User models need to adhere to (duck typing). So, a custom User model would say "for this User model, the email address is stored in the database field called 'email'" -- or "this User model doesn't have email addresses." I chatted about this with Jacob on IRC, and we reached consensus on this approach. I'd like to get moving on this and would be happy to take it on myself, starting next week. Adrian -- 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.
