Hacker News Reader

Comment by fzzzy | Hacker News Reader

When I first became interested in mvc, it wasn't quite as buzzwordy as it is today, and so I went and read the original smalltalk source. What I discovered was that the role of the controller in smalltalk was to poll the mouse and keyboard in a tight loop. When I wrote webmvc (which became woven, which became nevow) I found, as I think many people have found, that the controller doesn't really have as much of a place on the web, and nevow ended up not really having controllers associated with views but rather the logic associated with a controller was placed in methods on the Page object.

I'm curious what role the controller objects play here.

View on HN

Answering my own question: the controller object contains a bunch of on* methods which seem to handle the raw browser event objects and manipulate the model and view accordingly. This makes sense.

However, the way the methods are connected appears to be the uiActions attribute of the view object, which seems unnecessarily tight coupling between the controller and view. Also, the example code makes the view code responsible for querying the form, when it seems this should be the responsibility of the controller.

For some reason I still have a gut feeling that the view/controller split can allow generic views with custom controllers or generic controllers with custom views, but in the real world it seems the view/controller separation is still extremely fuzzy.

Morphic, the ui framework used by squeak, does away with the controller concept, leaving input handling up to the Morph (view) which is an interesting data point.

fzzzy,

Thanks for taking a look at Maria. You definitely got the gist of how things work with Maria but there are a few subtleties that might change your perspective on the relationship between views and controllers in an app built with Maria.

If a view has the following

    maria.ElementView.subclass(myApp, 'MyView', {
        uiActions: {
            'click .alpha'   : 'onClickAlpha'   ,
            'mouseover .beta': 'onMouseoverBeta'
        },
        ...

That auto-generates two methods on the view that forward handling to the controller.

    myApp.MyView.prototype.onClickAlpha = function(evt) {
        this.getController().onClickAlpha(evt);
    };
    myApp.MyView.prototype.onMouseoverBeta = function(evt) {
        this.getController().onMouseoverBeta(evt);
    };

So it is actually the view that handles the DOM events.

If you don't want the controller to handle the raw DOM event or you don't want a controller involved in handling the event at all, you can define the handler methods on the view yourself and then the auto-generated methods will not be created. For example,

    maria.ElementView.subclass(myApp, 'MyView', {
        uiActions: {
            'click .alpha'   : 'onClickAlpha'   ,
            'mouseover .beta': 'onMouseoverBeta'
        },
        properties: {
            onClickAlpha: function(evt) {
                // not sending evt to the controller
                // and controller method name is different
                this.getController().onSomething(1, 2, 3);
            },
            onMouseoverBeta: function(evt) {
                alert('no controller involved here');
            },
            ...

Also about who should query the form data: the view or the controller. I believe the view should be the only player in the game that knows about the DOM. If the way that the form data has to be retrieved from the DOM changes, then only the view needs to be updated. This makes sense to me as the view is the one that creates the form so the view should encapsulated all access to the form.

In the real world, the view/controller separation can be fuzzy. With Maria you can easily live without any controllers and have the views handle all user events or you can go wild with controllers and have all kinds of interchangeable view behavior thanks to the flexibility provided by controllers and the strategy pattern.

Thanks for the excellent reply!

I'm still interested in hearing a convincing argument for decoupled controllers. Your statement that the view should be responsible for DOM interrogation rings true to me, and seems to reinforce the idea that the view should just handle input instead of splitting it out into a controller.

A controller and the strategy pattern allow a view to behave differently by plugging in a different controller into the view. This interchangeability of behavior is not something I've leaned on frequently in my own programming.

I am finding, while programming example applications for Maria, that splitting the event handling out to the controller is forcing me to make better APIs on my views to keep the DOM encapsulated. Allowing the controller to get the form data, without exposing any DOM information, for example. The view code ends up being very satisfying in a way I haven't experienced before.

What I'm hoping will happen is that after using strict view and controller separation for a while, I'll start to get insights where the strategy part could be used more. I think its the kind of thing that will sneak up on me over time and I'll start to see more uses for it.

Are not the event objects technically part of the DOM, though? It seems to me the view should unpack the event objects, and then delegate to a controller method, passing only non-DOM-related data. The controller then contains the "business logic" which is what everyone seems to put in controllers anyway.

You're right about the event being part of the DOM. If that is a concern, you can define your own view handlers that unpack the DOM event and forward the data to the controller handler. There is no way to autogenerate view handlers that know what needs to be unpacked in what way.

Reply on news.ycombinator.com