On Wed, Mar 21, 2012 at 2:41 AM, Clay McClure <c...@daemons.net> wrote: > > I assume also that most changes would be relatively minor: dropping the > username field, or "fixing" the email field (where the developer gets to > define what that means), but not, say, removing all of the authorization > attributes required by the admin. >
Authorization and authentication are definitely orthogonal, and I would hope that whatever proposal for pluggable auth.User models gets accepted goes ahead and turns the current implementations of both into pluggable pieces that can be reused separately. There's another big use case for plugging into the User model: auth backend per-app storage. There's currently no good way to distribute a backend that stores access keys, openid identifiers etc. because profiles are per-project. I think a pluggable User model will prove to be strictly superior to profiles because of this. To be clear on the ModelForm issue, though, is it correct to say that any > LFK proposal must also provide LMFs (Lazy ModelForms)? > Anything that refers to the User class object has to be made lazy. Pluggable models, if made general and used commonly, would basically dictate a high-level architecture that consists of a lot of meta-programming expressed through lazy references and class attributes, resolving as the first requests make their way through the project. -Alex Ogier -- 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.
