Bruno Desthuilliers wrote: > Do you mean the code effectively doing these operations is in the gui ? > If yes, it would be better to factor it out IMHO.
The GUI has to be able to acces the data object, otherwise how does the user affect any changes to the application data? If I modify a value in a text box and hit Apply, that change must be propagated to the data model somehow. Similarly, the GUI must access the data to display it. Actualy this has nothing to do with code modules. The problem is is you have one object that contains your data, and your app consists of several objects that need to interact with it, how do these other objects access it? I'm fairly new to OOP and Python so I don't know it's scoping rules very well. Simple example: One way would be to use the database as the point of contact for all the object. Every object that wants to read or write to the database instantiates an object to interact with the database and performs whatever actions it needs. That way each top-level objecyt will contain it's own instanced database IO object. Their only point of contact with each other is the database itself. This could lead to synchronisation problems though. Another way would be to create one instance of the database IO object and then pass it as a parameter to the other application objects when they are created. The point of contact between the application objects would be the single database IO object, with the database behind it. This seems to me to be the superior approach. Are there any other architectural options that anyone could suggest? Simon Hibbs -- http://mail.python.org/mailman/listinfo/python-list
