Let me start by saying I haven't read over this entire post (only briefly on the initial thread).
For messages, why not switch these to using sessions? We have implemented anonymous (on-demand) sessions locally, it could be very useful to do this in general. On Dec 19, 8:51 am, David Danier <[EMAIL PROTECTED]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
