MVC with Python

Marco Bizzarri marco.bizzarri at gmail.com
Tue Sep 16 14:47:02 CEST 2008


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:
>>>
>>> Hello,
>>>
>>> I need some advice on how to implement model-view-controller. I am trying
>>> to
>>> develop a GUI application with PyQt, yet the problem rather applies to
>>> mvc
>>> in general, not just GUI applications.
>>>
>>> Let's say the data is a list of objects with a common base class. The
>>> views
>>> are either a graphical representation of the objects or some form of
>>> textual
>>> input. The views shall change the model by using command objects (for
>>> undo,
>>> e.g. QUndoCommand).
>>>
>>> My current approach is to implement the model as a class with a list-like
>>> interface, with methods insert(), remove(), __getitem__(),
>>> __setitem__(),...
>>> and a signal to notify the views. The objects in the list have methods to
>>> change their state as well.
>>>
>>> My problem is, how do the commands interact with the model?
>>> Let's say I have a command that modifies an object o in the list.
>>>
>>> 1) If list[key_to_o] returns a reference to the object, the command can
>>> modify the object by using this reference, i.e. list[key_to_o].setX(). So
>>> there is no way for the list to know when the object changed - how can it
>>> emit a singal then?
>>>
>>> 2) If list[key_to_o] returns a deep copy of the object,
>>> copy_of_o = list[key_to_o], the command mofifies the copy and the updates
>>> the list: list[key_to_o] = copy_of_o. Now the list can emit a signal in
>>> __setitem__().
>>> While this may work, it seems awkward to copy around objects just to
>>> perform
>>> a possibly simple operation on them. Additionally it might not be
>>> feasible
>>> once objects get complex.
>>>
>>> 3) The interface of the classes of the objects could be reflected in the
>>>  list class, i.e. list.set_x_on_obj(key_to_obj,x). This would probably
>>> make
>>> the list class interface very bloated.
>>>
>>> Of course the problem is not really limited to Python, my apologies if
>>> I'm
>>> totally off-topic here.
>>>
>>> Regards
>>> Georg
>>>
>>
>> Well, I think one of the assumptions of the MVC is that the view can
>> be notified about the changes in the model. According to your
>> interface, the View can just be notified on operations about the
>> *whole* model, like adding or removing elements from it.
>>
>> But the elements of your list-like class should be a part of your
>> model, and therefore should be able to notify the Views by
>> themselfves.
>
> Ok, consider this: say the model needs to compute some sort of value by
> iterating over all objects in the list (for example some sort of hash). Some
> kind of view then displays this value.
> I could implement this by connecting a signal in each object to a slot in
> the list class which in turn emits a signal which is connected to the view.
>
> 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.

Regards
Marco

>
> Regards
> Georg
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>



-- 
Marco Bizzarri
http://notenotturne.blogspot.com/
http://iliveinpisa.blogspot.com/



More information about the Python-list mailing list