Article Todo Mvc 2 Hmvcp
TODO:
Rewrite the code in this article mvc-with-js to refactor it and express a simpler way of doing things.
MVC
is a design pattern that breaks an application in three layers:
- Model: Handling data (Model).
- View: Presentating data to the user.
- Controller: Reacting to user interaction.
Introduce conventions. A way to reduce boiler code. Introduce the path to an abstraction. How we go from the article to an implementation where we have an interface. The View provides two methods:
View.prototype.listensTo = function(){
return this.eventList;
};
View.prototype.onSystemEvent = function(event){
var handler = 'on' + event.type.capitalize();
};
The Proxy
- ViewController
, Mediator
or Presenter
class listens for System wide events, and acts as a translation layer. That is easier to justify on larger systems.
In a small application, it could be as simple as a method on the Application
level, that manages the wiring.
Application.prototype.registerView = function(view){
var events = view.listensTo();
events.forEach(function(e, i, a){
this.emmiter.on(e, view.onSystemevent.bind(view));
}, this);
};
A View's responsability
In this article, a view's responsability, the author introduces the idea of a view's responsability, gives us some compelings reasons why this is a good idea, and then lists the duties:
- Rendering the view, i.e. making changes to the DOM.
- Listening for DOM events, such as click and submit.
Listening for events from the rest of my application, plus triggering events when the view is in certain states.- Creating sub-views if they are needed.
Updating models based on changes in the view (Don't you dare make $.ajax calls directly in views!)
I would argue that actually, the responsabilities are:
- Encapsulating a view component. Generally related to the DOM.
- Listening for user events. Usually DOM events.
- Relaying user events that affect application state.
- Updating the proxied component when external- to the view- events occur.
Views should wrap a UI control
Thats it. Maybe, the term View is confusing. I think of it as Content View.
If we break a view in subtypes, we can have- another- list:
- Layout View
- Theme View
- Content View I would say that 1,2 should be offhanded to the browser HTML/CSS.