Where does he do this stuff? I'm guessing much of it is done via ring middleware, but some of it doesn't fit there, and it doesn't fit in the view or model either.
To me the rules are pretty clear:
* data-processing stuff belongs in models
* business-logic belongs in *business models*,
if said logic is related to the UI (i.e. repeat-password),
although for simplicity you can choose not to bother
* request processing (authorization, choosing the models,
choosing the view) belongs in a controller action
* response processing belongs in a view
And you can't do those things based on your framework in either, a general config of the app or a simple declarative manner, that fits into a simple function that decides which view to render, based on data?
Also shouldn't form validation be a mapping of data to your "domain objects" and let them decide if they're valid?
regarding validations, my models do decide if a from submission is valid, but the controller then decides what to do if the submission is invalid. I.e. serenader the form with some error messages. This is a good example of something that makes more sense to me in a controller.
In Django, which does not have controllers either, you'd do this via a view decorator in the URL dispatcher: the URL dispatcher is essentially the "plugin point" for the framework-provided controller(s)
Django styles itself as MTV: Model Template View. The concept of "Controller" within Django I would say gets implemented across a few layers (Urls, middleware, decorators and return HttpResponse objects).
I never cared much for the distinction though as long as everyone knows what your nouns mean for the specific project you could call them RedFish, BlueFish, OneFish frameworks and it would work just as well.