I totally agree with what you say - and (if I understand you right) that´s exactly my point.
it seems like a compromise. we don´t need first_name, last_name and email for user-authentication. it´s just there because of an assumption what users might need (or not). some notes below: Am 10.09.2006 um 22:38 schrieb James Bennett: > > On 9/10/06, patrickk <[EMAIL PROTECTED]> wrote: >> 1. why are these personal values (first name, last name, email) there >> in the first place? did I miss something? > > The User model is not meant to be an exact match for the needs of 100% > of all possible authentication use cases; instead it's meant to match > the needs of most basic authentication use cases. > > And, really, there is absolutely no possible set of fields for users > which would make 100% of developers happy; there would always be > someone saying "I don't need this field, why's it in the model" or "I > need this other field, why isn't it in the model". So Django provides > a basic model with fields for things that people commonly want to > have, and provides a means of extending the model through a related > profile model. I agree. and it´s not about making people happy (well, sometimes it is). it´s about what makes sense and what not. > >> 2. when using a custom manipulator for letting the user change his >> personal values (first name, last name, address, zip_code ...), I >> have to change 2 different tables (user and userprofile). that doesn >> ´t seem to be clean ... ??? > > What would be the alternative? Or, rather, what would be a workable > alternative? in my view, anything that´s not needed for user-authentication belongs to a user-profile. for me (and I may be wrong here) a user- profile is for personal information (like first name, last name, address and what have you). if we strip the user-model to the fields relevant for user- authentication and describe a way to extend it (I know you did that), we could almost make those 100%. there is 2 different users: 1. the one who can use the given model ... fine for them. 2. the user who wants to extend the model. right now, for user nr. 2 the given model stands in the way of extending the user-model. one has to split personal information to 2 tables (not funny). in my view, it´s much cleaner to have user nr. 1 to extend the basic user-model ... > > The problem here is that offering a built-in auth system means that > there *must* be some baseline of fields which Django apps can assume > will exist in the User model. Which means that a free-for-all "define > only the fields you want" system couldn't work; inevitably, some app > somewhere would decide, say, that it was safe to assume fields named > "username" and "password", and then someone would try to install it on > a system where they'd customized away those fields. > > So there is no single-table solution. I know and I never said there should be. > > People often suggest model subclassing as an alternative, but that > doesn't really work either; what people want from extending the User > model is "this model becomes the User model" and what they get from > subclassing is "this model becomes a User model". > >> 3. why not let the django-user decide what he wants? when we don´t >> need the personal values for authentication, why does django not >> support a userprofile where the user/developer defines the table he >> needs for a specific application (not everybody needs a first name, >> but it´s still there ...) > > It's there, but it's optional. If its existence in the database > offends you to an extreme degree, edit the model class directly and > drop that column from your DB :) problem with upgrading django ... thanks, patrick > > > -- > "May the forces of evil become confused on the way to your house." > -- George Carlin > > > --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
