> If it is apocalyptically destructive to your application for there to > be tables it doesn't use, then this is a problem.
Thats not really the problem, even if I don't really like it and don't think it's what perfectionists like either. > If you don't mind the fact that you won't be using the defaults, then > this is not a problem. True, but having to duplicate every app in django.contrib I want to use (and which uses django.contrib.auth.models.User) only because the ForeignKey is wrong, that's bad in my opinion. And fixing the admin will not really help with this issue. So I think it would be nicer to really fix the problem in django.contrib.auth, not django.contrib.admin. If for example django.contrib.auth.models would do something like "from the.place.where.i.put.my.auth.models import User" every application importing User from django.contrib.auth.models would just work...if you provide some basic API the application needs of course. Now putting the creation of Message and LogEntry-objects into it's own methods in ModelAdmin is not even half the fix you need: * Having to override this methods is not really much cleaner than the other ways to accomplish this * Every third-party-application will need this change, as they will not use your ModelAdmin-derivate by default * Some parts of django do not use these admin-methods and should not do so (because this would bundle them to the admin), but they do use things like User.message_set Additionally this change will only help users in a simple way that don't care if they have Message or LogEntry available. Everybody else needs so put their own code into log_action() and send_user_message() to get a functionality that is already inside the admin, but only not working because some key references the wrong model (everything else would work perfectly). > Your complaints about code duplication are somewhat strange to me, > because I would assume that if you're supplying your own > authentication/permission scheme you would expect that things which > use the Django auth scheme simply would not work, and would have > supplied your own implementations of anything your system actually > requires. I did replace the django.contrib.auth mainly because I wanted (read: needed) to put a guest-user into the database instead of using AnonymousUser (I changed things of the User-model later, but thats what got me started). So my model and everything else was just like the application django provides. Sadly all of the other things django provides (which use django.contrib.auth) did not work afterwards. A simple fix would have been to replace the django.contrib.auth-module itself (I love that Python allows this from other modules), but it seemed hackish to me. Patching django is an option, but only if you know, that your patch might probably go into django. Otherwise you will need to maintain this patch forever. So forking django.contrib.auth was my way to go. And it way certainly easy, as I really only needed to fix some imports and remove the following line to get the admin working again: http://code.djangoproject.com/browser/django/trunk/django/contrib/admin/views/main.py#L29 > Meanwhile I'm not really sure why you'd fall back to emulating things > like message_set -- just remove the auth context processor and (once > this change to newforms-admin gets sorted out) there shouldn't be > anything which needs to access that. If there is anything which needs > to access that, bring it up and we'll see if it can't be changed. One example might be the generic-views, as stated in my previous email: http://code.djangoproject.com/browser/django/trunk/django/views/generic/create_update.py#L42 Some user in IRC told me that putting your own "user"-variable into request forces you to rebuild _all_ of the users API, but I think renaming your is even more hackish...and of course the code does not even check if request.user exists, so a user-variable needs to be put there anyway. Strictly speaking putting send_user_message() into ModelAdmin does not help at all, because some apps might use User.message_set. LogEntry is declared inside django.contrib.admin, this is different, but Message is something django.contrib.auth provides. So wrapping the creation of Message-objects inside the admin does help to fix the admin, but there may be other parts of the code or other applications that use Message. Perhaps instead adding User.send_message() could help, but removing the Message-functionality certainly does need someone to do similar things like what I've done by replacing User.message_set. As said before: I did replace django.contrib.auth, so I know what trouble you run into doing so. So trust me, only adding these two methods will not be enough to _really_ support users that want to replace django.contrib.auth. Of course these methods help people running the admin without django.contrib.auth, but that's all. No django.contrib.comments or other stuff that needs User-objects (and no re-usablility of third-party-apps without code-changes). But after all I think only unbundling the admin could be done with some if-statements inside the admin-code without needing the user to do anything at all. Doing so you might even skip having LogEntry (if is_installed("django.contrib.auth"): class LogEntry()...). As for log_action() this could be done this way: -------8<------------------------------------------------------- class ModelAdmin(...): [...] if is_installed("django.contrib.auth"): def log_action(self, user, action, ...): user.logentry_set.create(action, ...) else: def log_action(self, user, action, ...): pass ------------------------------------------------------->8------- (Note: is_installed() is some imaginary function I used, there might be something in django to do this, but I think it's clear what I try to say even if the function name is wrong) As stated some weeks/month ago in an email about my "auth-rewrite"-branch: I'm willing to help. Being able to replace django.contrib.auth gives some nice advantages, even over the current backends-system. For example you do not need to sync your db with LDAP when using LDAP as the backend. A User-model only containing the DN would be enough here. 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 -~----------~----~----~----~------~----~------~--~---
