On 4/3/07, Max Derkachev <[EMAIL PROTECTED]> wrote:
> 1. app_label, model_name = settings.AUTH_PROFILE_MODULE.split('.')
> 2. model = models.get_model(app_label, model_name)
>
> First, it does not behave properly if the settings.AUTH_PROFILE_MODULE
> is something like 'path.to.app.models.Profile'.This is largely something which needs to be dealt with via documentation; 'get_model' is the standard Django internal method of specifying a model to retrieve (and I've used it in more than a couple apps of my own as well). Documenting 'get_model' and the format AUTH_PROFILE_MODULE needs to be in will be the solution here. > Second, models.get_model(app_label, model_name) enforce that the > profile object must be a Model subclass and should be in > INSTALLED_APPS. I think this is worth living with -- the standard use case will be that it's a Django model class, and if it's not it becomes a nightmare trying to accomodate every possible way of associating a class instance with a User. Requiring it to be a Django model with a relationship back to User makes the API simple, and doesn't really impair functionality -- even if you're using custom auth classes, you need to persist them somehow, and if you're already using Django's ORM (which you are, if you're using the User class) then the Django ORM is the logical way to do that. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
