> The application creators weren't thinking about interoperability of their > applications because there are no such guidelines for making interoperable > applications. Interfaces and componentization would give Django the > opportunity to define some standard interfaces like IUser and give Django > developers the opportunity to define interfaces for other things, such as > Satchmo having the ability to define IPostalAddress. What you called IUser interface must be base class then. Customizing users model was better discussed in other threads. With real solutions given. Not "make all stuff components and interfaces and have fun connecting them". You propose just additional abstraction layer with no benefits. Python is not Java. You can call any object method without subclassing it from interface allowing such method. User is already IUser. You can even change used user model with middleware. > 2) Interfaces are not python way of doing stuff. google: duck typing. > > > Please take my arguments into account and reconsider your idea with them. > > 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. Django is a framework, not a library. That means you have to change framework anyway if it's not flexible enough. All parts of application can't be flexible at the time, do you agree? I remember someone told me about Microsoft application, that took data path in registry then xml-object under that path, then created COM object from part of that xml data, then calling XML-RPC to another component of the same computer just for retrieving one boolean property value. Great flexibility, right? You want to teach Django to do that trick? You have come too late. Your django applications are components, middleware and backends are components. The component structure is present and working already. What else do you want? When someone will write function get_user_model_class() for you? I guess, you want to have exactly the same errors with User model that you had with profiles :) (some application working with custom-User-model-1 only, another - working with custom-User-model-2 only). The only correct solution is to create your own table for additional user data and store all your information there. And just install your User model by yourself.
"Class factory for greater flexibility" pattern makes sense in Java world only. Ok, last story. Once I copied Java homogeneous class hierarchy of 5 classes (100 lines each) to python and refactored it. Result was 4 functions of 3 lines each. In Java I won't be able to live without these 5 classes. Factories and class hierarchy disappeared. Because they were not necessary in Python! --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
