[wxPython-users] wxPython and MVC

[Mark Erbaugh]

Harry,

Thank you for your comments. You have given me somethings to think
about.  

On Mon, 2007-12-03 at 12:59 +0800, Pan Xingzhi wrote:
>     Normally people regard things like wx widgets and web pages as
> view. What you're doing is adding another abstract layer between
> controller and view (the 'view' data member in the controller object),
> so ideally you may change the view without affecting the controller.
> However, in most cases the controller is allowed to be coupled with
> view (maybe except for the web development, where view and controller
> may not even reside on the same machine). Think about this: even if
> you apply the 'view' data member, you still have to modify it if you
> change the UI from wx to web. So is it really necessary to encapsulate
> this modification in this 'view' data member rather than just
> modifying the controller? 

In this design, the 'view' data member is simply a reference to the
wxFrame instance.  The methods that store and retrieve data from the
wxFrame instance are just members of that object.

>     That depends on how much you need on changing the face of your
> software ;-) But my suggestion is, don't overdo it. A lot of people
> tend to invent "imaginary requirement" and then find themselves
> devoting 80% effort on 20% (or less) of the functionalities. 

A very good point. I have a tendency to over-engineer things and to
spend too much time creating an elegant solution to something that never
becomes a problem.

>     You don't even need to make controller an object. Python doesn't
> force this, neither does wx. In my opinion, a set of functions in a
> Python module is enough. My point is that, the controller rarely has
> its own state, and its job is to manipulate model and view rather than
> providing APIs to change itself. OO gains little benefits here. 

Something to think about. I had assumed that the controller would keep
track of the current record and implement calls to a generic model
object. There would be only one instance of the model for a given screen
regardless of the number different instances of the same screen (each
with its own controller instance).

Thanks again,
Mark