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. Carl
signature.asc
Description: OpenPGP digital signature
