If i recall on IRC the decider was to just create a display field (e.g. user.data["display"]) that the default profiles can provide (and can be overridden by other profiles of course).
On Monday, April 2, 2012 at 9:17 PM, Anssi Kääriäinen wrote: > On Apr 3, 3:35 am, Jacob Kaplan-Moss <ja...@jacobian.org > (http://jacobian.org)> 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: > > > > * Vastly "prunes" the required fields on auth.user. The only things left > > are an "identifier" (which could be username, email, url, uuid, whatever), > > and a password. > > * Introduces a new "profile" system that provides a way to contribute extra > > related fields. Multiple profiles are supported, along with some syntactic > > sugar for dealing with multiple profiles in a reasonably reusable way. > > > > And that's about it. I'm deliberately trying to find a middle ground > > between "do the minimum to allow people to move on" and "throw out and > > rewrite django.contrib.auth entirely". I'm not expecting everyone to be > > thrilled by this idea, but I'm hoping that this is "Good Enough" for almost > > everyone. > > > > For more please see the document. Please do try to read the whole thing: > > I've had a few rounds of feedback incorporated already, and there's even an > > FAQ at the end. > > > > I'm not using BDFL fiat here, at least not yet. This is a proposal, and I > > very much want to hear feedback, objections, and alternatives. I'm > > particularly interested in hearing from people who've got complicated auth > > needs and think this absolutely won't work for them. > > > > I *have* reviewed all the other proposals and I'm between -0 and -1 on all > > of them. This means that if you don't like my proposal, you'll probably > > have to come up with a complete *new* idea to have any chance of getting my > > vote. > > FWIW I am +1 on this proposal. This is assuming that forms, queryset > handling of the data and so on actually work correctly and nicely. I > don't see a blocker in those areas, but before the code is actually > written and tested it is impossible to say if there will be problems. > Devil is in the details and all that. > > I hope this will not result in hacks to allow .filter(data__) and so > on. I believe we should aim for as generic solutions as possible. If > we do hacks just for the User model, they _are_ going to cause > problems later on. Most of the features needed would be neat to have > regardless of the User refactor. Custom lookups per model/field for > example would be _really_ neat feature. The downside of aiming for > generic solutions is that we once again get into the situation where > User refactor is blocked by implementing foo, bar and baz before it. > > I believe this is the right way forward. Multiple profiles makes sense > in the SQL world, and in the NoSQL world you would just embed the > profiles into the User document. I don't believe performance will be a > problem in practice, at least as long as you don't add too many > different profiles to be loaded by default. The most common use case > will just get better support: you have user profile containing three > fields, and then you have all your local fields defined in one > profile. As now, you have profile + user, now they just model your > data properly. > > I don't see a proposal of how __unicode__ is going to be handled (the > Hello, UserName requirement). My proposal: go through the profiles in > the order they are defined, and pick the first one having __unicode__ > defined as the default __unicode__. If there is no such profile, > return identifier. > > - Anssi > > -- > 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 > (mailto:django-developers@googlegroups.com). > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > (mailto:django-developers+unsubscr...@googlegroups.com). > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
