On 9/7/07, Joshua 'jag' Ginsberg <[EMAIL PROTECTED]> wrote: > Sure. Walks, quacks, yep. It's a duck. But if I want my own user model, I > don't just have to make something that looks and acts like a User from > django.contrib.auth -- I have to convince everybody else to use my version > instead of the django one. But applications that need a User-like object can > query to see what installed components implement IUser instead of just > assuming I want to use django.contrib.auth, then it's much easier.
But keep in mind, when you start talking about outright replacing existing implementations, you're going to run into deeper issues. Remember, there's an underlying database that has to keep track of relationships among the various tables, so if you change from one User model to another, you'll likely have to scrap everything that ever dealt with the User model. It's one thing to provide a generic interface for something that probably hasn't already been implemented, but to replace things already in core, you give developers a big problem: if I want to use your application, I have to abandon everything I've already done, because you needed to have another method on the User model. And I don't expect the schema evolution code would help much with this problem either, unless it goes in a new direction to explicitly handle this. Instead, I think we could look into ways of extending existing models (even to the point of adding new fields!) in a way that schema evolution would readily understand. Then, we might have a decent way to deal with things like this. -Gul --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
