views:

1769

answers:

3

I'm wondering what the common project/application structure is when the user model extended/sub-classed and this Resulting User model is shared and used across multiple apps.

I'd like to reference the same user model in multiple apps. I haven't built the login interface yet, so I'm not sure how it should fit together.

The following comes to mind:

project.loginapp.app1
project.loginapp.app2

Is there a common pattern for this situation? Would login best be handled by a 'login app'?

Similar to this question but more specific. http://stackoverflow.com/questions/464010/django-application-configuration

UPDATE

Clarified my use-case above. I'd like to add fields (extend or subclass?) to the existing auth user model. And then reference that model in multiple apps.

+3  A: 

You should check first if the contrib.auth module satisfies your needs, so you don't have to reinvent the wheel:

http://docs.djangoproject.com/en/dev/topics/auth/#topics-auth

edit:

Check this snippet that creates a UserProfile after the creation of a new User.

def create_user_profile_handler(sender, instance, created, **kwargs):
    if not created: return

    user_profile = UserProfile.objects.create(user=instance)
    user_profile.save()

post_save.connect(create_user_profile_handler, sender=User)
Tiago
+1: login required is just a decorator on the view functions. Not a separate app,
S.Lott
Ok, thanks! It seems I still don't quite have my mind wrapped around this yet.
monkut
With this extra info, you should follow tokenmacguy's answer plus checking the django book http://djangobook.com/en/1.0/chapter12/ in the Profile section. Also, I'll edit my answer with a snippet that creates the UserProfile automatically when a User is created.
Tiago
Thanks, I'll add the django tag.
monkut
+2  A: 

i think the 'project/app' names are badly chosen. it's more like 'site/module'. an app can be very useful without having views, for example.

check the 2008 DjangoCon talks on YouTube, especially the one about reusable apps, it will make you think totally different about how to structure your project.

Javier
I agree. I think they named almost everything in django wrong.
TokenMacGuy
+6  A: 

Why are you extending User? Please clarify.

If you're adding more information about the users, you don't need to roll your own user and auth system. Django's version of that is quite solid. The user management is located in django.contrib.auth.

If you need to customize the information stored with users, first define a model such as

class Profile(models.Model):
    ...
    user = models.ForeignKey("django.contrib.auth.models.User", unique=True)

and then set

AUTH_PROFILE_MODULE = "appname.profile"

in your settings.py

The advantage of setting this allows you to use code like this in your views:

def my_view(request):
    profile = request.user.get_profile()
    etc...

If you're trying to provide more ways for users to authenticate, you can add an auth backend. Extend or re-implement django.contrib.auth.backends.ModelBackend and set it as your AUTHENTICATION_BACKENDS in settings.py.

If you want to make use of a different permissions or groups concept than is provided by django, there's nothing that will stop you. Django makes use of those two concepts only in django.contrib.admin (That I know of), and you are free to use some other concept for those topics as you see fit.

TokenMacGuy
+1: Profile is very handy.
S.Lott
+1 in addition, you don't necessarily need to use the built-in AUTH_PROFILE_MODULE and it's helpers. if you can separate your user settings into different logical components, each can have their own model referencing a foreign key to the User model
Daniel
Thanks, this looks like it's going do do what I need!
monkut