Re: auth.user refactor: the profile aproach

I completely agree with Adrian's proposal, with these amendments suggested by Russell in order to build something slightly more generic, like LazyForeignKey, instead of UserField. In fact, a UserField coud end up being provided as a subclass of LazyForeignKey with a default name provided (e.g.

Re: auth.user refactor: the profile aproach

On 04/04/2012, at 4:34 AM, Adrian Holovaty wrote: > On Tue, Apr 3, 2012 at 9:28 AM, Alex Ogier wrote: >> I have written up a little bit about the alternate proposal that I made a >> while ago, Solution 2a >> from https://code.djangoproject.com/wiki/ContribAuthImprovements > > ... > 4. Third-par

Re: auth.user refactor: the profile aproach

On 04/04/2012, at 4:42 AM, Carl Meyer wrote: > On 04/03/2012 02:34 PM, Daniel Sokolowski wrote: >> Correct me if I’m wrong but both LFK or a swappable user model approach >> like your fail to address issue of extensibility. If today my project is >> authorizing with username and password and tomo

Re: auth.user refactor: the profile aproach

On 04/04/2012, at 4:31 AM, Carl Meyer wrote: > > By the way, I took the liberty of removing from the wiki page the > references to models/settings circular dependencies, because AFAIK the > statements made about it on the wiki page were simply incorrect. > Importing settings does _not_ immediatel

Re: auth.user refactor: the profile aproach

Thanks for the response, Adrian. > 4. Third-party models should be changed to use something like "user = > UserField()", which would automatically create a foreign key to the > registered User model. If you change your registered User model after > you've created those third-party tables, you're

Re: auth.user refactor: the profile aproach

+1. Also, I'd like to help. :) L On April 3, 2012, at 15:34 , Adrian Holovaty wrote: > On Tue, Apr 3, 2012 at 9:28 AM, Alex Ogier wrote: >> I have written up a little bit about the alternate proposal that I made a >> while ago, Solution 2a >> from https://code.djangoproject.com/wiki/ContribAuth

Re: auth.user refactor: the profile aproach

On 04/03/2012 02:34 PM, Daniel Sokolowski wrote: > Correct me if I’m wrong but both LFK or a swappable user model approach > like your fail to address issue of extensibility. If today my project is > authorizing with username and password and tomorrow I wish to add > OpenAuth then my User model is

Re: auth.user refactor: the profile aproach

Like Carl I was +1 on Profiles and I'm now leaning towards the Swappable User Models. It's explicit (it only changes when you change the USER_MODEL setting). It's Duck Typing which is Idiomatic in Python. ("This app depends on a user model that defines ``email`"). If you wish to add OpenID y

Re: auth.user refactor: the profile aproach

Alex I have looked over your proposal and I agree on both your concerns with LFK, and Jacob’s approach; however I still find the profile approach is the most flexible solution. Correct me if I’m wrong but both LFK or a swappable user model approach like your fail to address issue of extensibil

Re: auth.user refactor: the profile aproach

On Tue, Apr 3, 2012 at 9:28 AM, Alex Ogier wrote: > I have written up a little bit about the alternate proposal that I made a > while ago, Solution 2a > from https://code.djangoproject.com/wiki/ContribAuthImprovements I just now got around to reading Jacob's solution and Alex's solution. Thanks t

Re: auth.user refactor: the profile aproach

On 04/03/2012 08:28 AM, Alex Ogier wrote: > I have written up a little bit about the alternate proposal that I made > a while ago, Solution 2a > from https://code.djangoproject.com/wiki/ContribAuthImprovements > > In addition to other arguments, there is a point-by-point breakdown of > what I feel

Proposal: upgrading the choices machinery for Django

A nice HTML rendering of this proposal is available at: http://lukasz.langa.pl/2/upgrading-choices-machinery-django/ == Upgrading the choices machinery for Django == Specifying choices for form fields and models cur

Re: auth.user refactor: the profile aproach

So, after reading this, I think I really only have a couple questions/concerns: 1. What, if anything, is the primary key on the base User model? Is it the identifier? If so, can it be specified as the primary key, rather than unique=True, db_index=True? If it's not the primary key, is it the usu

Re: [GSOC 2012] Customizable serialization

W dniu 03.04.2012 15:55, Tom Christie pisze: It breaks the problem down into two very well defined tasks. 1. Convert native datatypes to/from data streams. (eg. Tastypie's serializers , REST framework's rende

Re: auth.user refactor: the profile aproach

DISCLAIMER: I'm just a hobbyist posting to an experienced developers' list. I for one really like Jacob's approach. I may be missing something, but my only concern right now is being able to infer which profiles are attached to the User model at any given point. Moreover, I'd like to be able to c

Re: django admin missing meta tag for charcter encoding in the head

On Tue, Apr 3, 2012 at 12:37 PM, Ric wrote: > hi, > > the default django template need a meta tag for character encoding in > the head > > > why? the Content-Type should be properly served in the HTTP headers... (if it isn't, then you have a genuine bug) Regards, D. -- You received this me

django admin missing meta tag for charcter encoding in the head

hi, the default django template need a meta tag for character encoding in the head -- 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, s

Re: auth.user refactor: the profile aproach

Hi developers, I have written up a little bit about the alternate proposal that I made a while ago, Solution 2a from https://code.djangoproject.com/wiki/ContribAuthImprovements In addition to other arguments, there is a point-by-point breakdown of what I feel are the weaknesses in Jacob's proposa

Re: [GSOC 2012] Customizable serialization

Hi Piotr, I'd really like to see something along these lines making it into Django. I worked on this during the 2011 DjangoCon.eu sprints, which I posted about a while back

Re: auth.user refactor: the profile aproach

Hi Jacob, Thanks for taking the time to tackle this issue! On Tue, Apr 3, 2012 at 2:35 AM, Jacob Kaplan-Moss wrote: > Hi folks -- > > I've written up a proposal for how *I* would like to address refactoring > auth.user: https://gist.github.com/2245327. > > In essence, this does two things: > > *

Re: auth.user refactor: the profile aproach

On Tuesday, April 3, 2012 at 3:37 AM, Tai Lee wrote: > I like this proposal because I am a big fan of a stripped down `User` model > which is basically just an ID, whic provides a common hook into > groups/permissions and other django and 3rd party profiles. > > What I don't like is the magical

Re: auth.user refactor: the profile aproach

I like this proposal because I am a big fan of a stripped down `User` model which is basically just an ID, whic provides a common hook into groups/permissions and other django and 3rd party profiles. What I don't like is the magical `data` bag (accessing `User.data` and filter lookups), the new