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. > 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? 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. 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 :) -- "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 -~----------~----~----~----~------~----~------~--~---
