MVC with Python

[Georg Altmann]

Maric Michaud schrieb:
> Le Tuesday 16 September 2008 14:47:02 Marco Bizzarri, vous avez écrit :
>> On Tue, Sep 16, 2008 at 1:26 PM, Georg Altmann <george at george-net.de> wrote:
>>> Marco Bizzarri schrieb:
>>>> On Mon, Sep 15, 2008 at 9:37 PM, Georg Altmann <george at george-net.de>
>>>> wrote:
>>> But this implies all the objects in the list have to be instances of
>>> QObject. I wonder if this is isn't a weird design, because for example
>>> all value type classes in Qt don't derive from QObject, e.g. QString. My
>>> list objects are not that simple (in terms of the data structure). So is
>>> it ok to make them QObjects?
>> Did you take a look at this?
>>
>> http://www.potu.com/man/doc.trolltech.com/4.0/model-view-programming.html
>>
>> It seems to imply that you should use QtAbstractItemModel as a base
>> class for all your models. But since I'm not an expert about Qt, I
>> cannot really say.

Yes, I did. But as I explained in my previous message, the whole Qt 
model-view framework doesn't seem fit any data which can not be handled 
as QVariant and thus as a value type.

> It is not about QT, it is about MVC. In MVC, code which implement the model 
> should be completely ignorant of the libraries used for gui, and the gui part 
> of the application shouldn't acces directly to your model logic. This why 
> there is a third layer which abstract the logic of your datas and provide 
> standard operation for the gui code. This third layer (Controllers), should 
> be as few as possible coupled to the specificities of the gui library (but 
> must be).
> 
> The  quoted papers explain rather well how to do this with QT (apart they call 
> controllers "delegates").

Except they always handle simple data. I don't see how to get around the 
QVariant limitatation. Also the data should be displayed in a graphical 
manner (maybe a QGraphicsScene/QGraphicsView or mabye custom 
QScrollArea). This also doesn't seem to go well with the standard Qt 
approach.

I could imagine to implement the model without using any Qt then use 
proxy classes derived from QObject as controllers.

> For medium to big project, don't be afraid to divide your program in three 
> packages, one for the model, in which you must not have any reference to QT 
> API of some sort, one for the controllers, where you provide events and 
> methods to manipulate your model, one for gui, where you just build windows, 
> subscribe to controller's events and use their functions as callbacks for 
> your widgets.

As this is a small project for now, I think the controller layer is too 
much work. As the project gets bigger it should be possible to switch to 
a full mvc implementation if necessary. For now I will try to work with 
a model that provides some signals by itself.

Regards
Georg