Patches to Django
0 views
Skip to first unread message
Sriram Panyam
Nov 9, 2009, 1:46:23 AM11/9/09
to sydney-djang...@googlegroups.com
Folks,
Thought I might put it out there. I mean technically this is not limited to django. I need to extend the django.contrib.auth.models.User class (adding an extra field, making the email field unique and increasing the length of the username field).
Now what are your thoughts on doing this? Changes are clearly very small and extending what is there so they will not break the existing classes and apps (or other django apps out there) so I dont mind putting these changes to each version of django I use.
I am not happy with doing this but I cant see a way around it. Adding another model class with these extensions just means that existing apps wont take advantage of this. Ideally I would like to see all apps and methods out there take the class variable that refers to the User model to be used so one could simply pass that in (say in settings.py) and it could even default to User model in django.contrib.auth.
What are your thoughts?
RoR guys if any here. What do you think and how would you approach this?
cheers
Sri
--
Blog: http://panyam.wordpress.com
Twitter: @panyam
Thought I might put it out there. I mean technically this is not limited to django. I need to extend the django.contrib.auth.models.User class (adding an extra field, making the email field unique and increasing the length of the username field).
Now what are your thoughts on doing this? Changes are clearly very small and extending what is there so they will not break the existing classes and apps (or other django apps out there) so I dont mind putting these changes to each version of django I use.
I am not happy with doing this but I cant see a way around it. Adding another model class with these extensions just means that existing apps wont take advantage of this. Ideally I would like to see all apps and methods out there take the class variable that refers to the User model to be used so one could simply pass that in (say in settings.py) and it could even default to User model in django.contrib.auth.
What are your thoughts?
RoR guys if any here. What do you think and how would you approach this?
cheers
Sri
--
Blog: http://panyam.wordpress.com
Twitter: @panyam
Elena Williams
Nov 9, 2009, 3:04:14 AM11/9/09
to sydney-djang...@googlegroups.com
We come up against this periodically and I believe a standard solution is to make another app to support the other details that you would like, such as contact details. I would hazard to guess that 'django.contrib.auth' is intentionally left simple because additional details that might be required by diff projects vary so wildly. This the 'pythony' way to do it. I don't have James Bennetts'* book handy but IIRC there is a bit at the beginning about how it's better to have lots of elegant and dedicated apps than fewer big and all-over-the-place ones.
Then whatever additional details are associated with the 'User' can be used wherever and whenever necessary by clever use ofmagical powers query relationships (http://docs.djangoproject.com/en/dev/topics/db/queries/#related-objects).
Option A
You can make a simple app (which for the record I did the first time). This can be very small and simple and only needs to contain:
user = models.ForeignKey(User,)
email = models.EmailField()
Seriously.
Option B
You can get one of the incredible and elaborate ones that have been made by people who've already been interested in similar things and gone all out eg http://code.google.com/p/django-profile/ (this is what I'm more prone to doing now). IIRC the washington post one is mental also. Actually it's interesting to do this to pull down and have a look to see how they've handled it.
Hopefully this relates, even vaguely, to what you asked?
Regard,
Elena
*for the record this talk is good and well worth a watch if you haven't seen it.
Also, if you haven't seen it, per Russell Keith-Maggee's advice this is a must-see:
Then whatever additional details are associated with the 'User' can be used wherever and whenever necessary by clever use of
Option A
You can make a simple app (which for the record I did the first time). This can be very small and simple and only needs to contain:
user = models.ForeignKey(User,)
email = models.EmailField()
Seriously.
Option B
You can get one of the incredible and elaborate ones that have been made by people who've already been interested in similar things and gone all out eg http://code.google.com/p/django-profile/ (this is what I'm more prone to doing now). IIRC the washington post one is mental also. Actually it's interesting to do this to pull down and have a look to see how they've handled it.
Hopefully this relates, even vaguely, to what you asked?
Regard,
Elena
*for the record this talk is good and well worth a watch if you haven't seen it.
Also, if you haven't seen it, per Russell Keith-Maggee's advice this is a must-see:
Sri Panyam
Nov 9, 2009, 4:43:05 AM11/9/09
to sydney-djang...@googlegroups.com, sydney-djang...@googlegroups.com
Yeah that was what I was afraid of Elena. My situation is I would like to do authentiation for users logging in from extemal sites like fb or friend connect or Twitter auth etc. So my new user class would have an extra field for the site they are logging in from. Or alternatively the username itself could be suffixed with the sitename (say "<userid>#<site_name>"). The problem with the suffiximg method is that usernames are limited to 30 characters so that gets too restrictive.
Ok so what I have at the moment is a UserAlias model that captures the site specific username and sitename (this works pretty well with middleware and all) but this means this class can't be used with existing apps that work with or explicitly require a User model unless I clone these apps to work with the new class. What's worse is there is no way this is goin to work with app with things like the app engine model.
I guess what may be require is meta-django!!! Where the django apps take the class in their internal foreignkey fields in a dynamic way (perhaps settings.py) as long a the classes satisfy a certain contract (ie all custom User models would have th username email etc fields defined as a minimum)!!! And this wouldn't break existing apps as they would only see an interface rather a concrete clas eactime any way. Heck you could even change the metaclass to change the orm behaviour!!!
Hmmm don't know what I'm smoking.
Cheers
Sri
Elena Williams
Nov 9, 2009, 9:24:49 AM11/9/09
to sydney-djang...@googlegroups.com
Heya Sri,
Have you done a search to see if someone has made a reusable app that does exactly what you're after?
There's lots of sick stuff out there that some clever people have spent much time doing the agonising over already, eg, http://github.com/uswaretech/Django-Socialauth
I'm thinking you probably need an elaborate diagram of some kind :)
---
regards,
Elena
Have you done a search to see if someone has made a reusable app that does exactly what you're after?
There's lots of sick stuff out there that some clever people have spent much time doing the agonising over already, eg, http://github.com/uswaretech/Django-Socialauth
I'm thinking you probably need an elaborate diagram of some kind :)
---
regards,
Elena
Sri Panyam
Nov 9, 2009, 10:15:10 AM11/9/09
to sydney-djang...@googlegroups.com, sydney-djang...@googlegroups.com
Howdy
Thanks for that one dude. But socialauth seems fairly new (aug 2009). I've kind of written (and been using mine since around mid last year :). Also one of the key goals with mine was to ensure that it worked on both appengine (wih django ofcourse) and raw django with the native models on the respective environments without having to resort to appengine patch or other wrappers. Oh well have to think more on where I wanna go from here.
Cheers
S
Reply all
Reply to author
Forward
0 new messages