>
> I want to create user accounts for my website. The account can be either a
> person or a group. So for *person* account I want to get different
> information from them (such as First name, Last Name, ...), and for
> *group* account get different information (such as Group name, ...).
> Basically different form for *person* account and *group* account. The
> account itself will have a unique primary key ( such as username/account
> id).
>
How should I do it? Should I make one to one relationship with account and
> person, and the same with account and group? Or create just on Account
> model and place a choice field to choose between Person and Group? Or how
> do you prefer I should do it?
>
While there is a philosophical difference between a 'person' and a 'group',
for your use case, I don't believe there is a significant technical
difference between the two. It sounds like an 'entity' will be able to log
in either way, so ultimately you just have Accounts that are classified as
either a single-user or are representative of a larger swath of users.
You can treat them as totally separate entities, and there may be a
technical need to do so if your app requires tight coupling to specific
functionality for each classification. However, in many cases, you won't
treat either Account classification. I would do the following assuming a
somewhat naive approach since I don't have the details of your use case.
This is assuming that either a 'person' or a 'group' would be able to
directly log in to you app:
Simply use Account as your primary 'user' ('user' meaning the entity that
will allow for logging into the system and checking permissions, etc.).
Combine your Group and Person models directly into Account (if they are
both small), or as a single separate profile model (ie AccountProfile) if
you have more that a couple fields in each classification (usually better
to have a separate profile model in most cases). AccountProfile would
contain fields that pertain to both a 'person' and a 'group', but only the
fields in use for that particular classification would be populated.
For Account, you would add a field with choices to designate 'person' or
'group' classification (if you have many, or a growing list, you may need
an FK to a Classification model that contains all of your possible
classifications). Add a 1to1 FK from Account to AccountProfile. Account
should only contain fields that are used when authenticating the user
(username, password, etc.) and fields that would be needed on a regular
basis throughout the app (display name, menu avatar location, etc.). All
other fields should be moved to AccountProfile, which is manually and
infrequently loaded on an as-needed basis.
That being said, there may be justification to keep the profile models
separate for each entity type. You may have model methods that overlap as
well. A method like account.get_display_name() may have a different set of
actions for a person (return given + surname) vs. a group.(return given
name). The differences will need to be accounted for in each of your model
methods, or you may simply want separate models to avoid a collision in
behavior between the two entity types.
As far as UI design goes, I would recommend looking at django-formtools,
which provides the Django FormWizard that was previously integrated with
Django. Django-formtools will allow you to build a multi-step form (wizard)
that can provide different forms for each step based on the answers in the
previous step. It has a slightly steep learning curve, but is likely what
you need.
-James
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/CA%2Be%2BciVPWNGdGNdEpk--mrtBxa3f5ocV9OAF0UN%3D3BL%2Bu9Q7Ow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
