The page I am working on has a javascript function executed to print parts of the page. For some reason, printing in Safari, causes the window to somehow update. I say somehow, because it does not really refresh as in reload the page, but rather it starts the "rendering" of the page from start, i.e. scroll to top, flash animations start from 0, and so forth. The effect is reproduced by this fiddle: http://jsfiddle.net/fYmnB/ Clicking the print button and finishing or cancelling a print in Safari causes the screen to "go white" for a sec, which in my real website manifests itself as something "like" a reload. While running print button with, let's say, Firefox, just opens and closes the print dialogue without affecting the fiddle page in any way. Is there something with my way of calling the browsers print method that causes this, or how can it be explained - and preferably, avoided? P.S.: On my real site the same occurs with Chrome. In the ex
The main goal with MVP is decoupling of different aspects in the code. Normally, in JavaScript, there are 3 major such aspects:
ReplyDeleteEvent Handling
DOM manipulation
Server communication (AJAX calls)
For each of these concerns, there's a corresponding term from MVP:
EventHandling = Presenter
DOM Manipulation = View
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 MVC 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.
HTH
Take a look at knockout.js which is a MVVM framework for your web pages. It provides a really beautiful and easily extensible framework for linking a model and a view in a loosely coupled fashion.
ReplyDeleteCheck out angular project at http://angularjs.org/ and feel free to ask any question at mailing group.
ReplyDeleteIt's designed to work well together with jQuery.
Very useful for writing TESTABLE MVC JS applications.
I know this question is old, but I think it is worth mention here. My vote goes to Backbone.js. Even docs says it is MVC, I would say it is MVP.
ReplyDeleteVIEW = 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.
Check PureMVC out. They have also port to JavaScript.
ReplyDeleteSeems googles GWT use MVP: http://code.google.com/events/io/2010/sessions/architecting-production-gwt.html
ReplyDeleteI've actually implemented an MVC like approach in my last JavaScript project. I'm with you, it wasn't easy to determine what goes in the view and what in the controller, there is a lot of gray area.
ReplyDeleteThis was my approach:
Model - the data from the server came in a nice JSON object, so I left it as is.
View - tried to keep it "dumb" with dry UI functionality. In other words, it provided an API that allows changing any of the visual aspects. For example - setting the size, setting the title, changing colors, etc.
Controller - if the view is the puppet, then the controller is the puppet master. It was in charge of fetching data from the server and pulling all the right strings to give life to the UI. For example - in case of an error, use the viewer to display an error message, or when the data arrives parse it and then display it via the viewer.
Note - I decided to keep some internal logic in the view after all since it felt practical and independent of the controller. For example, handling tab overflow (what to do when there are too many tabs to display and not enough space). Not sure if it was the right decision in terms of MVC, because I read a guideline somewhere that the view should not call its own methods. However, so far so good.
Hope this helps, and best of luck.
Another one: http://javascriptmvc.com/
ReplyDeleteNever used it myself, but maybe it will help you out.
EDIT: Just a note that Ext JS v. 4.0 will ship in Q1 2011 with new functionality for generating MVC project structures and scaffolding on the client. I haven't yet tried it, but the preview I saw looked pretty good. Should be interesting to anyone interested in MV[C|P] on the client.
@Yanick "Usually, MVP is on the client, while MVC is on the server."
ReplyDeleteI think you misunderstand MVP (Model View Presenter). This pattern is very similar to MVC (Model View Controller) in that you attempt to separate concerns in your application. The main difference is how requests are handle as they are received. MVP exists because ASP.NET WebForms, which is a server side tech, cannot handle a pure MVC model. Check out this post for a good comparison.
As far as using it (or even MVC for that matter) in your JavaScript code, I think this is the wrong pattern for the job. I would also say that if you fell you need to use one of these patterns then you are over complicating your frontend but that's a discussion for another post. If you are dead set on using this type of pattern then go with MVC since MVP is really a workaround to get MVC like separation in ASP.NET.