MVC with Python
Georg Altmann
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
Marco Bizzarri
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.
Just my 0,02 Euros.
Regards
Marco
--
Marco Bizzarri
http://notenotturne.blogspot.com/
http://iliveinpisa.blogspot.com/
David Boddie
> 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 problem is, how do the commands interact with the model?
One approach that combines the undo framework with the model/view framework
is described here:
http://doc.trolltech.com/qq/qq25-undo.html
The implementation is in C++, but it may be possible to pick up some
useful tips from the article.
David
Georg Altmann
Thanks for the pointer. I studied the article before, but it doesn't
seem to work for my problem:
If I understand the Qt model/view architecture correctly, data is always
based on items which are wrapped into QVariant.
(see http://doc.trolltech.com/4.4/qabstractitemmodel.html#data)
So to use the Qt model/view architecture items have to be represented as
a value. I think this leaves me with the problem of copying objects I
described before.
Regards
Georg
Georg Altmann
>> 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).
>>
>> 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.
>>
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?
At least this seems to be better than making a copy of the object each
time it is accessed.
Regards
Georg
Marco Bizzarri
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
Maric Michaud
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").
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.
--
_____________
Maric Michaud
Georg Altmann
> Le Tuesday 16 September 2008 14:47:02 Marco Bizzarri, vous avez écrit :
>> On Tue, Sep 16, 2008 at 1:26 PM, Georg Altmann <geo...@george-net.de> wrote:
>>> Marco Bizzarri schrieb:
>>>> On Mon, Sep 15, 2008 at 9:37 PM, Georg Altmann <geo...@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