MVC with Python
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>
>>> I need some advice on how to implement model-view-controller. I am trying
>>> develop a GUI application with PyQt, yet the problem rather applies to
>>> in general, not just GUI applications.
>>> Let's say the data is a list of objects with a common base class. The
>>> are either a graphical representation of the objects or some form of
>>> input. The views shall change the model by using command objects (for
>>> e.g. QUndoCommand).
>>> My current approach is to implement the model as a class with a list-like
>>> interface, with methods insert(), remove(), __getitem__(),
>>> 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
>>> While this may work, it seems awkward to copy around objects just to
>>> a possibly simple operation on them. Additionally it might not be
>>> 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
>>> the list class interface very bloated.
>>> Of course the problem is not really limited to Python, my apologies if
>>> totally off-topic here.
>> 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
> 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?
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.
More information about the Python-list