Rajeev, How, then, would you suggest handling multiple user groups? To continue with a similar theme from above, let's say we had two user groups, Authors and Publishers. When signing up, an Author might need to input their first name, last name, email, and a password, but a Publisher would only need their publisher name, password, and maybe an email. We'd have to use a different signup forms to allow for the differences in first and last name, and publisher name. After creating an account, an Author might add profile information that is unique to Authors, and a Publisher might add profile that is unique to Publishers. Is this still not a candidate for subclassing? Are you suggesting that all information just be stored in the profile (including email, password, etc.)? Thanks for helping!
michael On Apr 30, 11:17 am, "Rajeev J Sebastian" <[EMAIL PROTECTED]> wrote: > On Mon, Apr 28, 2008 at 3:59 AM, 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: > > The main problem with this approach is multiple apps. For e.g., a site > may have a CMS, a blog, a forum, etc ... and if each app were to > subclass User ..... > > you get the picture. Thats why User should never be subclassed (for > this kind of purpose anyway). In fact, I would so far as to say "never > use inheritance, unless you really know what you are doing". of > course, Inheritance being the first thing people teach about OO doesnt > help at all. > > regards > Rajeev J Sebastian --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
