Passive view in JavaScript

I'm thinking about an implementation of MVP - Passive View pattern in JavaScript. In most case the view will be simple dom elements where the presenter attaching event listeners. But when it comes to widgets like JavaScript based pseudo selectboxes, auto suggest or aria features, should this be part of a JavaScript view class or should the logic to change the view be part of the presenter? I've looked at the javascriptMVCs view and it seems that they are only template generated html without any logic. But for me there seems no different between a presenter who's listenen to html selectbox and one who listenen to an pseudo selectbox with javascript logic to mimic a real select box. Both shouldn't care about how the box is working internally, they just have to listen the change event.

So what to you think. Whats the job of vie开发者_如何学编程w class.

---

The View object should be responsible for drawing itself. A Passive View knows how to do stuff, not what to do. It must be responsible for firing its own events. Just because it is a custom select box widget does not make it any different than a regular select box.

If the presenter took over all the views responsibilities, then there is no need for a view at all. Might as well just have a presenter only.

---

The view's job is as an adapter to the view technology. In this case, your view technology is likely jQuery over HTML via JavaScript. The view should be designed to do three things:

• Know when events occur, and communicate these events to the presenter (this may be indirectly, using a messaging framework like postal.js)
• Tell the presenter (when asked) "what is the value of x" where x is a value represented in the view.
• Accept messages from the presenter (usually through a direct method call) to change the values on the view.

A view in the passive view pattern is not stateful. I repeat, a view does not represent state. What I mean by this is that all state and knowledge of state transition is represented by the presenter. The view is simply the glue that provides indirection between the presenter and the actual view technology. Beyond the three bullet points above, it does not encapsulate any knowledge of what to do with the information it contains. This is important, because you should never expect a view to be in a consistent state. You should always hold the presenter responsible for managing the state of the view.

The stack above demonstrates how I foresee the model, view, and presenter interacting, as well as their relationship to the view technology and the controller.

• The browser, HTML, and DOM (managed through jQuery) are the view technology. These are inherently complex, and incapable of representing your model.
• The view protects your logic from the view technology. It provides indirection so that you can focus on plain old code in your presenter. The view should use some sort of messaging in order to communicate back to the presenter. This prevents a bidirectional dependency between the view and the presenter. It also allows multiple presenters to manipulate a view.
• The presenter should be responsible for understanding the abstract nature of the view, and should manage the model's state based on its interface to the view. It is capable of understanding how to retrieve a model from the contoller, and how to persist the model back to the server.
• The model is a representation of state at a specific point in time. It can also serve as a DTO between the controller and the presenter. In JavaScript, it is easy and sometimes preferable to simply add presenter behavior on to the model.
• The controller coordinates the navigation within the application, and is responsible for abstracting the back-end services from the presentation.

---

JavaScriptMVC's views are dummy client side templates. It's node controllers tend to take on a more traditional View role.