26

Has anyone been able to implement the MVP model with any javascript frameworks? I'm having trouble figuring out how to have the presenter -> view inversion from server code to javascript. I have some ideas, but kind of hackish and would like to see what others are doing.

  • 2
    Why? I'm no old-school 'JS is devil's work' guy, but even if you have large client-side apps, I don't see the benefits but just the overhead. – Boldewyn Jul 14 '09 at 12:24
  • 5
    @Boldewyn, If you're not old school, then consider that HTML5 and Javascript go right along each other. If you think JS is "devil's work", then I think you never learned the language. True, Javascript can become very messy quickly, but once structured, it can be quite powerful and versatile. Plus, TraceMonkey (Firefox) and V8 (Chrome) are quite efficient and even faster engines will be released in the future. And I'm not mentioning the fact that more and more applications go online, and prone client side execution over server side. If you're no old school, you should know all this..... – Yanick Rochon Aug 03 '10 at 03:56
  • 1
    @Yanick Rochon: Actually, JavaScript is the most lovely language I know. What I meant was, that I can't see the benefits of a JS *MVP* framework that go beyond a well-design *server-side* MVP framework. Why do it in the browser and load all the stuff, when you can also do it server-side? – Boldewyn Aug 03 '10 at 06:47
  • 3
    @Boldewyn, why a JS MVP? Because if you're putting your MVP on the server side, then you missed the concept of MVP :) With MVP, your model is strictly on the client and the server is used merely as a "storage" facilitator. Usually, MVP is on the client, while MVC is on the server. You can actually use them together to have structured code both on the client side and also on the server side. – Yanick Rochon Aug 05 '10 at 15:34
  • 1
    @Boldewyn: The whole point is to put most of your application logic on the client-side so as not to bog down your servers with it. I find it much easier to write an application when you can directly control its state without having to go through a web server. This also makes the application snappier because it doesn't need to wait for Ajax requests for simple computations. – Sasha Chedygov Dec 13 '10 at 05:08

3 Answers3

48

The main goal with MVP is decoupling of different aspects in the code. Normally, in JavaScript, there are 3 major such aspects:

  1. Event Handling
  2. DOM manipulation
  3. Server communication (AJAX calls)

For each of these concerns, there's a corresponding term from MVP:

  1. EventHandling = Presenter
  2. DOM Manipulation = View
  3. AJAX calls = Model

Since indeed it is not always simple to implement the 3 aspects, an EVENT BUS may come in handy. This bus should be a singleton and all the events, raised in various context should be published on the bus. The Presenter needs to register to its events and react accordingly when events happen.

Here is how it would work:

First thing that happens is the page load. Listen to this using the normal event model or jQuery or whatever is convenient. Create the Model, the View and the Presenter. The Presenter needs to hold the View and Model instances since he's gonna use them.

var model = new Model();
var view = new View();
var presenter = new Presenter(model, view);

Remember that Presenter is the event handler so the bus should know about it and route events to it for handling:

bus.registerHandler(presenter);

The first event is the "init", which means the page has loaded and the MVP objects are all set:

bus.init(); // call this yourself

This would trigger something in the Presenter, like a function. I prefer the on... naming convention, in this example presenter.onInit(). This gives a chance to install UI listeners:

// in the Presenter
onInit: function() {
  view.addSubmitListener();
  view.addWhateverListener();
  ...
}

// in the View (using jQuery)
addSubmitListener: function() {
  $("#submitButton").click(function() {
    var formData = ...
    bus.submit(formData); // publish an event to the bus
  });
}

When the Submit button is clicked the bus.submit(formData) is called and this will route it to the handler -- presenter.onSubmit(formData):

// in the Presenter
onSubmit: function(formData) {
  model.postForm(formData, function(data) {
    // handle the response
    view.updateSomething(data);
  });
}

And so on... The entire trick is binding the bus to the presenter and then you're in the loop.

desertnaut
  • 57,590
  • 26
  • 140
  • 166
Neovibrant
  • 747
  • 8
  • 16
1

My vote goes to Backbone.js. Even docs says it is MVC, I would say it is MVP.

  • VIEW = html template (jQuery.template)
  • MODEL = Backbone.Model
  • PRESENTER = Backbone.View ( layer between your view-tempate and how to bound data to it, and more thins you can do) and what is best you can use in render method couple views (html templates) or switch which to use...

and what is best you still have controller

  • CONTROLLER = Backbone.Controller

Alternative could be as @JoshRivers mentioned, knockoutJS but my personal opinion is that view template is overwhelmed with binding stuff.

And last note. Thing is View as V from either MVC or MVP is something which can be built from your template without coding it, make good HTML template parser and you are good to go :) Believe me, convention is your friend.

desertnaut
  • 57,590
  • 26
  • 140
  • 166
Milan Jaric
  • 5,556
  • 2
  • 26
  • 34
0

Another one, for jQuery folks: http://javascriptmvc.com/

Just a note that Ext JS also supports the MV(x) pattern since version 4.0, which I'll mention as an ex-Ext person. Like most frameworks, they too call it "MVC" (as does most everyone in the JS world, see TodoMVC, as opposed to TodoMVP). However from a practical standpoint, the tools are there in Ext to implement the C/P portion of the pattern as best fits your needs. Patterns are useful, but like most anything, can limit your thinking when treated dogmatically.

Brian Moeskau
  • 20,103
  • 8
  • 71
  • 73
  • 1
    As the name states, it's MVC not MVP! – niutech Jan 17 '14 at 01:30
  • @niutech For all practical purposes, MVC and MVP are interchangeable concepts on the client, and any library that claims to be one or the other will certainly provide similar application patterns. The distinction between "Controller" and "Presenter" means a little more on the server, but on the client I'm not sure there's much of a distinction. Perhaps you can enlighten me. – Brian Moeskau Jan 21 '14 at 05:26
  • I think [this](http://stackoverflow.com/questions/4733700/what-is-the-difference-between-controller-in-mvc-pattern-and-presenter-in-mvp-pa) explains it well. In MVC, models communicate directly with views, whereas in MVP, the presenter is the middle man which listens to models' events and updates views. – niutech Jan 21 '14 at 23:59
  • My point is that the difference is primarily semantic/academic in the real world. Most people interchange different MV* patterns with the same intended meaning, and most frameworks do the same. Most real-world implementations blur the lines that you seem so eager to enforce. I would think there are better things out there to spend your downvotes on. – Brian Moeskau Jan 25 '14 at 07:41