I just started learning about extending Django's User model, so bear
with me as I make sure I understand these things correctly. So we can
subclass the User class doing something like:
class Reader(User):
fields...
class Author(User):
fields...
Does this mean that any new instance of Reader or Author will also be
found in User (or some reference to Reader and Author)? I understood
this to be the case based on peschler's UserProfile class:
class UserProfile():
user = models.OneToOneField(User)
fields...
So this will allow you to create a universal UserProfile class for
Readers and Authors as opposed to doing something like:
class AuthorProfile():
user = models.OnetoOneField(Author)
fields...
class ReaderProfile():
user = models.OnetoOneField(Reader)
fields...
Also, what's the difference between OnetoOneField and ForeignKey?
Does it make a difference which one you use? Thanks in advance for
your help.
michael
On Apr 27, 3:29 pm, peschler <[EMAIL PROTECTED]> wrote:
> On 25 Apr., 21:40, "Marty Alchin" <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > Not to get too much into this discussion, but I tend to be slow to
> > understand design patterns and other paradigms. What then would be the
> > appropriate way to handle an app that managed authors? I can see two
> > possibilities:
>
> > class Author(User):
> > pen_name = models.CharField(max_length=255)
>
> > or
>
> > class AuthorProfile(models.Model):
> > user = models.OneToOneField(User)
> > pen_name = models.CharField(max_length=255)
>
> > Essentially, whether it has the semantics of an "is-a" or a "has-a"
> > relationship seems to depend solely on what name I give the class.
> > Clearly a user could "be an" author, while he/she could instead "have
> > an" author profile.
>
> > How would I proceed in a situation like this?
>
> I would tend to subclassing in this case. To make my point clear add
> another user model called "Reader" to the example:
>
> class Reader(User):
> stories_read = models.IntField()
>
> Assuming that only author's should have a "pen_name" and only readers
> should have a "stories_read" field, it would be feeling "not
> naturally" to put these fields in a profile (and therefore go the
> profile way).
>
> Furthermore assuming that your site requires *every* user (readers and
> authors) to specify their phonenumber (which is not part of standard
> User model), this should go into a profile:
>
> class UserProfile():
> user = models.OneToOneField(User)
> phone = models.PhoneField()
>
> That way you benefit from both. You have Authors and Readers which are
> users ("is-a"), and which both have a phone number ("has-a").
> From an OO standpoint you are now able to use Authors and Readers
> instances, whereever a User instance is used in the API. This is not
> possible when using a profile.
>
> Please be aware that I did not test the qsrf branch and the examples
> above and the way I understand things are maybe not how things work.
>
> peschler
--~--~---------~--~----~------------~-------~--~----~
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?hl=en
-~----------~----~----~----~------~----~------~--~---
