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 view class.
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:
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.