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 `data` bag (accessing `User.data` and filter > lookups), the new `AUTH_PROFILES` setting, and the idea of Django > automagically or lazily creating profiles for me. I would rather see Django > rely solely on its `OneToOneField` field to access user profile data. > > Any pluggable app (app1) will know what fields it's own profile model has and > how to access them, relative to the central `User` object. > > If app1 relies on fields defined by another app (app2), that other app should > be a requirement of app1 and app1 would know how to access app2's fields. > > I am happy to use project-level signals for everything else (syncing common > profile data from app1 and app2, or auto-creating user profiles), because > project-level signals give me explicit control over what is going to happen > and when. I don't need any more magic here. > > Cheers. > Tai. Without the `data` bag we've done nothing except rename the username field and make it longer really. Everything else that you define can already be achieved by ignoring the fields already on User and using OneToOneFields. With the `data` bag we allow a pattern kinda similar to class inheritance.
I think you also mistake the use case, it's not app1 relies on app2, it's app1 relies on _a_ field called email that provides an email address. It doesn't care where it comes from. If we do not provide a common way to access this data with this proposal, than a large number of apps are going to depend on the default profile, and we are stuck again here where everything depends on what Django Core decides for "first_name", "last_name", email length, etc. > > > On Tuesday, 3 April 2012 10:35:41 UTC+10, 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: > > > > * 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. > > > > Thanks! > > > > Jacob > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-developers/-/PMpcPCKgTuoJ. > 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.
