2.6.2 Advanced Controllers

While the previous section on Controllers offered a nice example with the Faren application, it does present some issues. First, the interface could use some extra niceness (deleting text from the entry does nothing!). Second, the controller has to invoke methods on its view's instance variables (self.view.celsius.set_text() for example), which is a sign of high coupling. One good way to solve these issues is to provide a subclass of BaseView that does some extra setup and provides an API for the Controller (faren2.py):


#!/usr/bin/env python
import gtk

from kiwi.controllers import BaseController
from kiwi.ui.views import BaseView

class FarenControl(BaseController):

    def convert_temperature(self, temp):
        celsius = (temp - 32) * 5/9.0
        farenheit = (temp * 9/5.0) + 32
        return farenheit, celsius

    def on_quitbutton__clicked(self, *args):
        self.view.hide_and_quit()

    # use changed instead of insert_text, since it catches deletes too
    def after_temperature__changed(self, entry, *args):
        temp = view.get_temp()
        if temp == None:
            self.view.clear_temp()
        else:
            farenheit, celsius = self.convert_temperature(float(temp))
            self.view.update_temp(farenheit, celsius)

class FarenView(BaseView):
    widgets = ["quitbutton", "temperature", "celsius", "farenheit",
               "celsius_label" , "farenheit_label", "temperature_label"]
    def __init__(self):
        BaseView.__init__(self, gladefile="faren",
                          delete_handler=self.quit_if_last)

    def get_temp(self):
        return self.temperature.get_text() or None

    def update_temp(self, farenheit, celsius):
        self.farenheit.set_text("%.2f" % farenheit)
        self.celsius.set_text("%.2f" % celsius)

    def clear_temp(self):
        self.farenheit.set_text("")
        self.celsius.set_text("")

view = FarenView()
ctl = FarenControl(view)
view.show()
gtk.main()

This (much longer, sure, but with a nicer division) example shows us using a separate View class, which presents an API for manipulating the View interface widgets, consisting of the following methods:

The Controller also uses changed instead of insert_text, so it supports both insertion and deletion.

This is basically what you need to know about the controller. While it is useful in a number of applications, if your interface has a number of widgets and rich interaction, you will notice that your View API will start looking like a exact copy of the widget methods. This is highly undesirable (as are accessor functions, for the same reason): it means the Controller is tightly coupled to the View, which is not what we want. And herein lies the main problem with the View/Controller split: if your interface is simple (as it is in our example), it's a nice way to separate things; however, if your interface is complex and has lots of widgets (I'd say a good rule of thumb is over 5 interactive widgets) you will end up with a lot of low-level View/Controller message passing.

(Another potential problem with the split is that neither the Controller nor the View are very reusable, which defeats part of the goals of modularity). The next section describes UI Delegates, which are combinations of View and Controller that simplify things somewhat.