Another way to do it is to create subclasses of all the relevant classes and forms. It's easy enough to create middleware that replaces django's default user object with your own, and it's also very easy to set the admin up to use your user model instead of the default.
On Aug 3, 3:15 pm, Dana <woodman.d...@gmail.com> wrote: > Yes, I agree that this is probably the best way to do it as I see now > and I may well do that change, Im just hoping that Im missing some way > to get around hacking up Django to get what I want... This seems like > the one thing in the framework that is suboptimal... too bad because > it is so crucial. > > On Aug 3, 6:26 am, cootetom <coote...@gmail.com> wrote: > > > When I first started using django I was surprised that it limited > > usernames and didn't allow email address's by default. It is probably > > the only thing in the whole framework that I have wanted to change. > > Yes it would be nice to have a clear solution rather than the approach > > I have taken which is to modify the source code directly. Although > > when I was faced with this problem originally I didn't like any of the > > solutions that were about. In my opinion, this sort of thing should be > > handled at the framework level. > > > On Aug 3, 1:36 am, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > > > > On Sun, Aug 2, 2009 at 11:56 PM, David Koblas<kob...@extra.com> wrote: > > > > > Just to add my $0.02 cents to this, I too would like a better way to > > > > extend django.contrib.auth.models.User than the current approach. The > > > > two biggest "problems" that I have are: > > > > > * Everything depends on django.contrib.auth.models.User -- which means > > > > that while you could swap out your authenticator you still basically > > > > have to go and rip apart everybody's applications to support your user > > > > object. > > > > * To the above point, it also means that to construct your own User > > > > object means you can't use contrib.admin since it depends on the User > > > > object. > > > > > What would be really nice is to have something like: > > > > django.auth.interface.User > > > > > Which in turn would instantiate something from settings.USER_MODEL > > > > (default contrib.auth.modes) this might mean you could subsume > > > > AUTH_PROFILE_MODULE into the USER_INSTANCE for most developers. Up shot > > > > is that I can now still use public applications and the admin system, > > > > but now somebody can just create a "facebook.models.User" class that > > > > mirrors using facebook as the authenticator and get everything for > > > > free... > > > > You aren't the first person to suggest this, and it's something I'm > > > interested in looking at in the v1.2 timeframe. This is a very common > > > question, and one for which Django needs to have a clear and well > > > documented solution. Ticket #3011 has one solution; I'm not completely > > > convinced that the patch on that ticket is the whole solution, though. > > > > Yours, > > > Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
