+1. Also, I'd like to help. :) L
On April 3, 2012, at 15:34 , Adrian Holovaty wrote: > 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. > -- 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.
