Model View Presenter GUI pattern?

[Pedro]

sorry about the previous lengthy and slightly off topic post...

George finds it hard to picture object creation and connexion
and so do I. Your code seems ok to me, but I think you should 
go a step further to picture some kind of framework that will 
work for you.

Currently there are two things that bother me :
- first subclassing a real, implementation dependent, widget 
- second explicit creation of a widget in your presenter

The first point may be addressed by the "anygui" library once
it will be available. This library also provides some 
notification mechanism that you may check.

The second point defies, IMHO, the ability to use a graphical
interface to draw your user interface.

I've try to address those two points, is using some kind of 
proxy-objects to access the widgets. These proxies will have 
the Observable interface to use the same notification
mechanism, and will associated with the real widget. The
widget will have to be retrieved from some factory class.

Pseudo code will look like this :

  [[abstract module ui.py]]

    class WidgetFactory:
        def __init__(self, designerFilePath): pass

        def getWidget(self, name): pass

    class IntegerWidget(Observable):
        class ObserverInterface:
            def valueChanged(self, widget, newValue): pass

        def __init__(self, factory, widgetName): pass
  
you could then create a specialized module for Gtk, another
for Qt, another for Tk that will implement the concrete class
for your toolkit.

This is a large amount of work to wrap all widgets in that way.
But since it only concerns the common behaviour of the widgets 
(view and controls) it is not as difficult.

By doing so you get ride of explicitly messing with object
layout in your code (with Gtk/Glade, you can embed the GladeXML
class, with Qt/Designer, you can pick up and evaluate the result
of pyuic compiler). And your presenter can be toolkit independent
(in your example, the connect mechanism comes from Gtk and does
not appear explicitly), with this framework you stick to your
notification mechanism.

I am wondering if the same reasoning couldn't be applied to the
model (consider a database and the database api).

Hoping this might be helpful and not confusing...


-- 

Pedro