Don't get me wrong - I'm not saying my way is right and I'm not saying
anyone is doing anything necessarily wrong.
I'm still a Django noob in a lot of ways.
Just things to keep in mind - if you do have multiple types of users
subclassing might be a bad idea if there are possibilities of being
classified as more than one.
"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 think here you're going to have about the same amount of work no
matter what method you go with. You can use save signals (or maybe
just overload save itself) to look at groups and add related info. I
have to hand it to you though - it's not going to be trivial no matter
what way you pick. The admin seems like it wouldn't be that easy to
deal with creating multiple subclasses of User.
"Creating the relationship between User and UserInfo has some
implications I'd like to avoid on a model-level"
Specifically what are you referring to here? Because anytime you
subclass in Django you are basically doing the exact thing in the
database behind the scenes and as result accessing the data turns out
to be pretty similar (just about as easy both ways).
You can also create managers on User - so you can do:
students = User.students.filter(...)
I'm definitely not saying you're wrong here BTW. I'm just giving an
alternative.
On Sep 24, 9:47 am, Axel Bock <mr.axel.b...@gmail.com> wrote:
> 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-mod....
> 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-i...
>
> * And this
> article:http://www.kolios.dk/2010/01/22/how-to-extend-django-user-class-and-c...
> 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.
