On Jun 16, 8:10 pm, Etienne Robillard <[EMAIL PROTECTED]>
wrote:
> On Mon, 16 Jun 2008 11:58:48 -0700 (PDT)
>
>
>
> radioflyer <[EMAIL PROTECTED]> wrote:
>
> > I've spent quite a lot of time reading through information about
> > extending Django's User model. I've read the arguments about
> > inheritance vs. user profiles. I've seen some posts in this forum
> > where the examples even used some of the same model scenarios that I'm
> > working with. Yet still...I need some help.
>
> > When I started organizing the data structures for my project, I began
> > by setting up some of the relationships I knew I would need. I didn't
> > start with the user authentication issue. Three of the models
> > (Student, Teacher, Parent) emerged as being a type of user. The
> > profiles of each of these users are becoming unique enough that one
> > 'UserProfile' definition does not seem sufficient.
>
> > User type models:
>
> > class Student(models.Model):
> >    parents         = models.ManyToManyField('Parent')
> >    teachers        = models.ManyToManyField('Teacher')
> >    sections        = models.ManyToManyField('Section')
> >    homeroom        = models.ForeignKey('Teacher',
> > related_name='homeroom_students')
> >    first_name      = models.CharField()
> >    last_name       = models.CharField()
> >    class_year      = models.CharField()
>
> > class Teacher(models.Model):
> >    sections        = models.ManyToManyField('Section')
> >    first_name      = models.CharField()
> >    last_name       = models.CharField()
>
> > class Parent(models.Model):
> >    first_name      = models.CharField()
> >    last_name       = models.CharField()
>
> > Other models:
>
> > class Course(models.Model):
>
> > class Section(models.Model):
>
> > class Task(models.Model):
>
> > It turns out, after trying various suggestions made by others, that
> > the most important factor is "Make it look right in the admin
> > interface." I don't want to start out a demo for a client by saying,
> > "Well there's this Student, User, UserProfile, thing that you have to
> > get used to" or, "You have to add a User, then add a Student, and then
> > make sure that you get the right User attached to the student" or,
> > "Well you don't see the Student's first name and last name, in the
> > Student listing because those are really attributes of the User."
>
> > Subclassing. Yes it's a problem if I want to use the same User/Student
> > over in my After School Sports application.
>
> > User Profiles.
> > How do you have more than one? And how do you do it without making a
> > mess of the Admin interface?
> > How about a UserProfile with one field, 'user_type' that Parent,
> > Teacher, Student could have a foreign key relationship to? That's
> > starting to look messy too.
>
> > Roles?
>
> > So. What would James Bennett and Malcolm Trednick do? And how would
> > they do it? :-)
>
> > This seems like problem deserving of a Django design pattern. I need
> > the help of someone smarter than I.
>
> > Regards,
> > Dan J.
>
> > PS. Sometimes a Teacher is a Parent. But, one thing at a time. ;-)
>
> Hi,
>
> I think a good design pattern you could try adopting
> is to name your profiles classes with a ending "Profile"
> suffix.
>
> For instance, rename a profile class for Teachers could be
> named TeacherProfile, and so on.
>
> That way I think its easier to remember which profiles belong
> to. Also, you could also define your own ``get_profile`` function:
>
> In example:
>
> >>> get_profile = lambda cls,pk: cls._default_manager.get(user__id=pk)
> >>> profile_data = get_profile(StudentProfile, obj.id)
>
> Assuming that a 'user' field exists for each profile models.
>
> To recap:
>
> 1. Name all profile classes/models with a common suffix
> 2. Define your own get_profile somewhere in case User.get_profile is not 
> appropriate for you
> 3. Forget about multi-table inheritance since its not stable yet -- Focus on 
> raw admin functionality first :)
>
> Hope this helps!
>
> Etienne

Etienne, Thanks for your reply. I'm working on my users with your
approach now.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to