Re-factoring To MVC pattern -Doubts on separation of view from controller

Answer 1

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.

Answer 2

wxPython has pubsub included, which follows the Publish/Subscribe methodology. It's similar to pydispatcher, although their implementations differ. The wxPython wiki has a few examples on how to use pubsub in your program and there's also this simple tutorial on the subject:

http://www.blog.pythonlibrary.org/2010/06/27/wxpython-and-pubsub-a-simple-tutorial/

MVC in GUIs isn't quite the same as it is in Django or TurboGears. I find that I can put most of my logic in controllers and in my "view", I just bind to the controller. Something like this:

view.py

btn.Bind(wx.EVT_BUTTON, self.onButton)

def onButton(self, event): controller.someMethod(*args, **kwargs)

Depending on what the calculation is, I may run a thread from my controller and post the result later using wx.CallAfter + pubsub.