> OK, so what you want is very very different from what I'm getting at here.
Yes and no, see below. > What I want == newforms-admin can be run without django.contrib.auth, > and people who do so understand that in doing so they are jettisoning > anything which relies on django.contrib.auth. True, but I think it would be nice being able to keep the log if users have their own User-model. > What you want == django.contrib.auth becomes a magical wrapper which > transparently switches out the entire auth codebase on demand so that > 'from django.contrib.auth.models import User' might do practically > anything depending on the configuration. Half true. Actually I'm trying to tell you that even if you change the admin the way you propose users will still run into serious trouble when trying to replace django.contrib.auth. This begins with not being able to use all generic views and probably ends with other apps using django.contrib.auth (django.contrib.* or third-party). > These are so very much unlike each other that I'm not even sure why > one came up in a discussion of the other. Perhaps I'm missing > something? As you try to improve the situation for users who want to replace django.contrib.auth I think it is the right place. First because there are some things that remain unresolved even with your proposed change, second because I don't think fixing every application on it's own is the right way to get the situation resolved in the long term. At least third-party apps will remain problematic even if everything inside django.contrib is fixed. But perhaps I'm to focused on the idea of reusable apps like the documentation states: "A project can contain multiple apps. An app can be in multiple projects." (http://www.djangoproject.com/documentation/tutorial01/#creating-models) If you are only interested in fixing the admin it might be displaced, but please consider the things that will remain broken even with your changes. One example still is: Being able to override/disable send_user_message() inside the admin does not do the job, as Message comes from django.contrib.auth, so apps outside of the admin will probably count on having user.message_set. And reading the code even generic views (which are outside of _any_ app!) do rely on Message. (see previous mails) Additionally I think putting solutions for common problems into the admin is the wrong approach. This was done when putting has_FOO_permission() into the admin instead of focusing on something like the "generic-auth" branch and using the permission checks introduced there (why should I need to add the admin-app only to have a nice and clean permission-framework?). It looks to me like the "unreplaceable django.contrib.auth"-problem will be fixed (or worked around) only in the admin now, without considering adding this functionality to the entire django-framework. Greetings, David Danier --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
