Should you use controllers in your MVC app? With Maria, it is your choice.

[Peter Michaux]

The split between domain data in the model layer and visual
representations of that data in the view layer with the two layers
connected by the observer pattern is likely the most valuable part of
the MVC architecture when creating browser apps. All the MV* framework
that I've looked into have this fundamental split.

The composite pattern in the view layer (i.e. a view having child
views) has also been very useful to me at work in complex UIs.

The third main pattern of the MVC architecture is the strategy pattern
thanks to controllers. At the discretion of a view, a view delegates
decision making to the view's controller. By changing a view's
controller, the behavior of the application can change when the user
interacts with the view, for example. The flexibility provided by the
strategy pattern and controllers has been the least valuable pattern
of the three main pattern of the MVC architecture in my work. I've
wondered and written about the utility of controllers openly...

* http://peter.michaux.ca/articles/mvc-architecture-for-javascript-applications

* http://news.ycombinator.com/item?id=4213137

As mentioned in that Hacker News comment, I feel that controllers have
made my view code better by encapsulating the DOM operations and
making my views less intelligent but I still haven't taken great
advantage of the ability to swap controllers in and out of a view. I'm
hoping that I'm just not noticing the opportunities yet and I will be
enlightened soon to the opportunities I'm missing. MVC is a long
journey.

What's important is that if you want to use Maria without controllers,
you can with ease. I showed how in the Hacker News but will show it
here slightly differently to completely eliminate controllers.

Suppose you have the following definition of a view

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

The code above 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. This also
shows you exactly where you can cut out the involvement of the
controller. If you don't want a controller involved, 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) {
alert('alpha was clicked. The view is handling it.');
},
onMouseoverBeta: function(evt) {
alert('beta was moused over. No controller involved here.');
},
...

Using Maria this way, you cut out the controller completely and
effectively have Maria work as an MV framework.

The controller implementation in Maria is very small. By far the
smallest of the model, view, and controller triad. You could quite
easily modify the Makefile to eliminate controllers from Maria. I
don't think it is worth the trouble to save a few characters of code.
And if you are like me, you'll have optimism that the utility of the
strategy pattern will suddenly appear as something you cannot believe
you hadn't been using all the time.