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 tomorrow I wish to add >> OpenAuth then my User model is replaced, whereas with Jacobs approach I >> add another profile model, yes? What about auth apps, you could only use >> one, with profiles many could co exist; one for Facebook, Twitter, etc. > > You would add whatever authorization fields you need to your single user > model. If you add new kinds of authorization that require new fields on > the user model, you'd do a schema migration (just like with any other > modification to any other model). > > A third-party app that wants to provide, say, Facebook integration, > could either do its own model with a one-to-one to user (nothing is > going to suddenly prevent that approach, it just won't have any extra > sugar around it), or could provide an abstract base class that your user > model can inherit from that includes the needed fields, or could just > document "to use this app, your user model must have these fields: ..." > and let you do it yourself.
Extending on this -- User model requirements should be encoded as part of an integration test suite. As an example of best practice, django.contrib.admin should implement a UserPropertiesTest that checks that the current USER_MODEL has an email field, and a get_permissions method, and so on. That way, if you swap in a user model that doesn't have the properties that the admin requires, it will get flagged as a issue during testing. This should, of course, be backed up with a clear documentation of exactly what type of User-duck Django's admin requires. Yours, Russ Magee %-) -- 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.
