Im trying to refactor my application (with 1000+ lines of GUI code) to an MVC style pattern. The logic code is already seperate from the GUI so that is not a problem. My concern is seperation of the view from the controller. I understand the basic principal of MVC and this tutorial in the wxpython wiki has been very helpfull but the code example is a little simplistic and leaves me with doubts when I try to apply the principal to my own project which is quite a bit more complex.
A snippet of the structure..
I have a MainWindow with a number of widgets including a noteBook (tabbed section),
the noteBook has a number of tabs one of the tabs (which I call FilterTab)holds two instances of a
class (that I call a FilterPanel)that is a panel with a listbox, three buttons, one to clear, one to remove and one to add items to/from the list. Depending on flags passed to the
class on instantiation the add buttons event can create different types of dialogs, eg a text entry dialog or directoryPicker etc..
Thats just one part of the GUI which is quite layered -with event handlers buried in the FilterPanel class.
If I were to convert that part to MVC I would have to bind the button events for each instance of the FilterPanel in my controller(instead of in the filterPanel class) -in this case there are two (filterPanel instances)
So I would have something like this for each button, (3 buttons per filterPanel * number of panel instances) plus the handlers..
self.mainWindow.filterTab.dirFilterPnl.Bind(wx.EVT_BUTTON,
self.onAdd_dirFilterPnl,
self.mainWindow.filterTab.dirFilterPnl.addBtn,
self.mainWindow.filterTab.dirFilterPnl.addBtn.GetId()
)
Which adds alot of extra code, (double the amount of event handlers if I have only two filterPanel instances)
So Id like to know am I taking the right approach?
If I were to convert that part to MVC I would have to bind the button events for each instance of the FilterPanel in my controller(instead of in the filterPanel class)
Not necessarily! MVC's philosophy and practice do not imply that "views" are elementary widgets; your FilterPanel could well be thought of / implemented as a "rich/composite" widget which generate its own, higher-level "events" (directed to the controller) and update appropriately. So, that composite widget can have handlers for lower-level "events" and synthetize higher-level events from them, sending them on to the controller; the controller does not have to know or care about every button etc, just about the higher-abstraction events it receives, such as "the user wants to pick a directory for purpose X" or "the user wants to enter text for purpose Y" -- and respond to them by telling the view what to do.
The key point is that the view takes no "semantic" decisions based on the events it handles, nor does it ever send any command to the model -- the controller is the indispensable "middleman" for all such interactions.
For an analogy, consider that the lowest layer of the GUI has very low level events such as "left mouse button down" and "left mouse button up" -- a "pushbutton widget" reacts directly to them by changing the button's appearance (a "visual" decision, not a "strategic" one) and eventually, if and when appropriate, synthesizing a higher-abstraction event such as "pushbutton was clicked" (when a mouse button down is followed by a mouse button up without intermediate mouse movements invalidating the "clicking" hypothesis, for example). The latter is then directed to whatever higher layer needs to "respond" to button clicks.
Similarly, your rich/composite widgets can take such events and synthesize higher-abstraction ones for the controller to react to. (The same abstract event could be generated by a pushbutton click, a menu selection, certain keystrokes... the controller doesn't care about these lower-layer "visual" considerations, that's the view's/widget's job, and the view/widget does not hardcode "strategic" decisions and actions to such user interactions, that's the controller's job).
The separation of concerns helps with such issues as testing and application flexibility; it's not unheard of, for such advantages to be bought at the price of having some more code wrt an alternative where everything's hardcoded... but if you choose MVC you imply that the price, for you, is well worth paying.
wx may not be the ideal framework to implement this, but you can subclass wx.Event -- or you could use a separate event system like pydispatcher for the higher-abstraction events that flow between separate subsystems, in order to decouple the controller from the specific choice of GUI framework. I normally use Qt, whose signals/slots model, IMNSHO, extends/scales better than typical GUI frameworks' event systems. But, this is a different choice and a different issue.