Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Suppose I want to implement MVC in JavaScript. I am not asking about MVC frameworks. I am asking how to build it in principle.

Let's consider a search page of an e-commerce site, which works s follows:

  • User chooses a product and its attributes and press a "search" button.
  • Application sends the search request to the server, receives a list of products.
  • Application displays the list in the web page.

I think the Model holds a Query and list of Product objects and "publishes" such events as "query updated", "list of products updated", etc. The Model is not aware of DOM and server, or course.

View holds the entire DOM tree and "subscribes" to the Model events to update the DOM. Besides, it "publishes" such events as "user chose a product", "user pressed the search button" etc.

Controller does not hold any data. It "subscribes" to the View events, calls the server and updates the Model.

Does it make sense?

share|improve this question

migrated from stackoverflow.com May 14 '12 at 22:51

This question came from our site for professional and enthusiast programmers.

    
Is your server also Javascript? –  superM May 14 '12 at 20:03
add comment

2 Answers

What you say make sense and it's the approach used in HTML5 frameworks like Sencha Touch 2 (http://www.sencha.com/products/touch/).

MVC is a pattern and is not tied to any specific language, framework or class library. So it is possibile to use it with Javascript also, regardless of specific technology employed.

share|improve this answer
add comment

Remember, the idea behind a pattern like MVC is to make your life easier. If you start ajaxing in static content to ram client side squares into MVC triangles you're not really doing that. We've already got the basics on the front end, like the DOM API that already manages the DOM tree, covered. Use MVC as a higher level layer of abstraction to make code more legible as well as easier to modify and implement. If it's already covered by the DOM API or even JQuery core, you're wanting to implement at too low of a level for it to be more help than hindrance, IMO.

I think on the front end it makes more sense to think in terms of how MVC can be used to apply to types of UI widgets rather than a way to deliver and handle all HTML content.

So imagine a combo box that lazy loads content when you click on it.

So you have a model with methods for communicating with the server to get the data and process it into something that's easy for the view to render. I would stop short of actually converting an array of items into LIs at the model and let the view handle that. The model triggers events when it is finished prepping/updating/processing data.

You have a view that handles rendering/re-rendering of list items inside your combo boxes and it also handles user interface stuff like auto-complete/match in the text box, and triggering app-level (not DOM - it translates those) events when new items are selected or an unloaded box is clicked on indicating a need for new data. The view also establishes context (which combo box is being acted on by a user).

The controller makes the app-wide/relevant decisions. So when a new combo is clicked on, the controller is what tells all the other combos to close. I think there is variation on this but it makes the most sense to me when model and views have to go through the controller rather than listen to or call each other directly.

So a view detects that a new combo has been clicked on and triggers an event the controller listens for. The controller determines that data is needed and triggers an event the model listens for. The model loads in and processes the needed data and when finished, triggers a completed event the controller listens for. Then the controller hands that data off to the view so the view can convert to LIs and drop them into the appropriate combo box.

Now, I don't love this as a triad of objects. It makes more sense to me for there to be a parent combo box object that essentially acts as a controller with aggregate model (if needed) and view/UI objects on the interior. That parent combo box object also manages state and maintains inventory of all the various combo boxes it's responsible for, which was more of a view responsibility in the triad model. What I like about this is that it's easier to make sense out of interaction with other objects and the combo box object itself gets all events pinged off of it, making them accessible to outside interests like a debug logger or other UI widget that needs to react to a combo box selection.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.