Hi. iPhoneから送信
On 2012/04/04, at 5:34, Adrian Holovaty <adr...@holovaty.com> wrote: > 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. Yes, Yes, Yes. I'm really glad someone besides me disliked user profiles and favored just creating your own user model. I was feeling lonely. Just like Adrian, me and everyone at my company have used our own user models for years. It always felt like the simplest and most straight-forward approach. It also has the be benefit that users can use south or anything they want. For migrating and managing user data. Big big +1. > 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. I wanted to point out that Adrien's plan is pretty close to newauth. Though I didn't go so far as to provide a UserField, I did have a way for third party apps to get a handle of the User model via a get_user_model() function. The UserField would just glue something like that to a ForeignKey. > 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 think people get too hung up on providing fields do third party apps when you could provide a minimal set of methods which subclasses could override. There isn't really any reason i can think of that third party apps need to access the fields directly. Though if you really hav to deal with fields, I prefer a simple convention for common fields; for example, 'email' for the email field. That way you can do a simple hasattr() to look if the model has a particular field. I realize convention is hard to document though. I'm curious though how the admin fits into your ideas. If you wanted to use the admin, would you have to use a User model that has and or supports all the cruft on the current user model? e.g. username, password, email, permissions etc. All in all I'm excited about where this is going and that you're taking the lead on this. Can't thank you enough. -- 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.
