We're not using Django yet but I think I have a good idea of how we'd use it in our framework. I'll try to summarize that in a few paragraphs, which hopefully will give you another idea of how to deal with the problem you present.
We use two modules per table, one has the "manager class" and the other modules has the bare model class and the "managed class." For example, if the name of the table is "servers", we then have serversmgr.py and servers.py. In servers.py you'd have two classes ServersData (the bare model) and the Servers class, which has all the logic related to servers and methods that operate on themselves, e.g., Servers.getIPaddrs(). Business rules' validators go in here too like say a "powerOn" method that ensures it can only be powered on if it has an IP address. The Servers class has a class attribute called 'data', which is a reference to an object of the ServersData class establishing a "uses" relationship with the model. We use duck typing here so we can replace the data object with a test model that "fakes" the database stuff and to use the same "logic" class with different models "adapted" to our interface, e.g., SQLObject, Django Models, or our own ORM. For example, the Django version of ServersData would import the django model from django/models/servers.py or django/models.py or wherever it is and then wraps it with our own interface methods, e.g., ServersData.store() would call Django's save() method. In serversmgr.py we'd have the ServersMgr class, which has all the CRUD methods, e.g., ServersMgr.new(), ServersMgr.delete(), ServerMgrs.update() and other stuff like ServersMgr.list() and other general methods like instantiators, e.g., ServersMgr.Object(name='fooserver'). In general, all the methods that operate on or produce the corresponding managed objects. (I guess these are what you called unclassed functions.) We also have a set of abstract base classes, MgrBase and ObjBase, where we put generic manager methods that operate on generic managed ObjBase objects. As you can guess I bet, ServerMgr is a subclass of MgrBase and Server is a subclass of ObjBase. The MgrBase class has a class attribute called moc (Managed Object Class), which in this ServerMgr class example will have it set to Servers, e.g., moc = Servers. This allows us to write generic methods in MgrBase that do generic stuff like self.moc.__name__ or instantiate an object by calling moc(*args, **kwds). The moc attribute is what links the manager module with the managed module. Similarly, ObjBase subclasses implement concrete versions of abstract methods like getMyManager() so that you write generic methods in ObjBase or MgrBase that operate on an object without caring what kind it is, e.g., mylist = object.getMyManager().list(**kwds). As you can see, this framework keeps the model completely bare and separates logic between the manager (list) and managed (validator) classes allowing the view to use the managers as the first point of contact. I'm sincerely curious to know what you guys think about this framework. -- Luis P Caamano Atlanta, GA USA --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~----------~----~----~----~------~----~------~--~---
