Join the DZone community and get the full member experience.
Join For FreeDeploying code to production can be filled with uncertainty. Reduce the risks, and deploy earlier and more often. Download this free guide to learn more. Brought to you in partnership with Rollbar.
- Read this article MVC Architecture for JavaScript Applications by Peter Michaux. It's a must-read and it nicely explains how the observer pattern works in the classic MVC. (Keep in mind that the MVC that you know from Rails/Django is a limited MVC, that's a topic for another post).
- Use Backbone and Underscore to handle events or roll your own observer mechanism (as described in Peter's article).
- (optional) Use CoffeeScript to make your code prettier.
Let me quote Peter Michaux:
In the GameBoxed platform, we have a Monopoly-like Facebook game. There's a concept of a player (this is the model). A player, after rolling a dice, can receive points and when he does we need to update the player-details box.
In a nutshell the classic MVC architecture work like this. There is a model that is at the heart of the whole thing. If the model changes, it notifies its observers that a change occurred. The view is the stuff you can see and the view observes the model. When the view is notified that the model has changed, the view changes its appearance. The user can interact with the view (e.g. clicking stuff) but the view doesn’t know what to do. So the view tells the controller what the user did and assumes the controller knows what to do. The controller appropriately changes the model. And around and around it goes.
In the GameBoxed platform, we have a Monopoly-like Facebook game. There's a concept of a player (this is the model). A player, after rolling a dice, can receive points and when he does we need to update the player-details box.
class Monopoly
constructor: (serverSide, popupsManager) ->
player = new Player(PlayerAttributes)
playerView = new PlayerView
playerController = new PlayerController(player, playerView)
(..)
class PlayerView
update: (player) ->
$("#player_score").text(player.points)
$("#player_ranking_position").text(player.rankingPosition)
$("#player_rank").text(player.rank)
class PlayerController
constructor: (@player, @view) ->
@player.bind("player:updated", view.update)
class Player
constructor: (attributes) ->
_.extend(this, Backbone.Events)
_.extend(this, attributes)
addPoints: (delta) ->
@points += delta
@trigger("player:updated", this)
When the page is loaded (our games are one-page apps, no full reloads), the Monopoly object is initialized. It's a facade object responsible for initializing models, views and controllers and wiring them together.
At some point thanks to some users actions the player.addPoints method is called which triggers the "player:updated" event with some arguments. Thanks to the controller (the bind method), the PlayerView object is notified that something interesting happened and the view updates the html (with some jquery helpers).
This pattern is very useful and can be used in most of the typical UI scenarios. Let me know what you think about it.
From http://andrzejonsoftware.blogspot.com/2011/09/3-steps-to-mvc-in-javascript.html
Deploying code to production can be filled with uncertainty. Reduce the risks, and deploy earlier and more often. Download this free guide to learn more. Brought to you in partnership with Rollbar.
Like This Article? Read More From DZone
Topics:
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}