Thanks a lot for your answers.
I thought subclassing users is a nice idea, cause a Student IS a user, with
a few extended attributes. I decided to subclass users, because ...
* when adding a UserInfo -> user relationship (class UserInfo(Model): user =
ForeignKey('User')), ALL users having a userinfo. this is bad if I have
different kind of users (I do.), so I do not really want that.
* A user can be created without attaching the UserInfo information (I did
this already, and unless I did something wrong, I could do just that). So I
have to add application logic to make sure that a Student actually has a
UserInfo object attached. Also because of my different system users it would
make no sense to actually attach that to EVERY user
* I have read this one:
http://scottbarnham.com/blog/2008/08/21/extending-the-django-user-model-with-inheritance/.
Subclassing models actually seems to be the "new" way of doing things, so
why should be User an exception to this rule?
* I also have read this article:
http://blog.picante.co.nz/post/Subclassing-User-to-add-extra-fields-in-the-Django-Admin-Site/
* And this article:
http://www.kolios.dk/2010/01/22/how-to-extend-django-user-class-and-change-authentication-middleware/(actually
the main one why I wanted this)
So, all in all, if it is possible AND a common way to go, I'd prefer it that
way. Creating the relationship between User and UserInfo has some
implications I'd like to avoid on a model-level.
If they are all wrong, I REALLY think the API should not let people do this.
If they are right, then I still lack an anwer for my problem - the single
f*cked up field in the create student form, which I'd like to shoot on sight
once it's there and then burn the ashes :) . (I have had not much sleep
tonight ...)
Thanks!
Axel.
2010/9/24 Vasil Vangelovski <vvangelov...@gmail.com>
>
> Mainly, I just don't think you're subclassing User for the right
>> reasons. In fact, I can't really think of anytime I would subclass
>> it. Usually adding a related table is a better way to go (lookup
>> django user profiles for example).
>>
>
> There are times when the builtin User model is not enough, that's why
> there is a way to specify user profiles. There are times when you want to be
> sure that every user in the system has a profile (some filed in the profile
> is required for the system to work properly), even for the users added from
> the admin. This can lead people to try all kinds of hacks, like subclassing
> user, which there is a way to implement but will lead you in all kinds of
> trouble. Then there is the case where you want all users to be staff no
> matter what, which makes the field superficial, but leads to extra
> uneccessary work on the developers part to make sure it works that way.
> These are all real world scenarios I've encountered, and I'm guilty of
> pushing a subclassed user model in the past.
>
> If the api leads a lot of people to try all kinds of hacks around it to
> achieve what they want, blame the API not the people. Providing concrete
> models for users in contrib leads to more pain than the time or trouble it
> saves.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com<django-users%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
