[fzzzy]

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.

[petermichaux]

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.

[fzzzy]

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.

[petermichaux]

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.