Comments on: MVC in the Browser

By: Kris Zyp

Kris Zyp — Wed, 22 Dec 2010 13:48:03 +0000

@Acaz: In proper MVC, a view can and should “observe” the model. This isn’t strictly a model initiated action/message, it is in response to the view’s observance of the model (but programmatically it does require a change in the model to be delivered to the view). The view responding to the model does not require going through the controller.

By: Acaz

Acaz — Tue, 21 Dec 2010 23:20:53 +0000

“The store will then send a notification event to the grid, which will update the view to eliminate the row corresponding to the deleted item. This follows proper MVC flow, with the controller affecting the model, which then affects the view.”

In MVC pattern, MODEL don’t communicate with VIEW, MODEL will pass the action to controller to eliminate the row corresponding to the deleted item.

I’m wrong?

By: Justin Meyer

Justin Meyer — Wed, 03 Nov 2010 18:46:40 +0000

I think Dojo could go slightly further in enabling this style of development than Dojo provides.

Dojo’s Model layer is Kick A. However, look at JavaScriptMVC’s controller …

http://javascriptmvc.com/docs/jQuery.Controller.html

for something that provides a really awesome way of handing binding/unbinding events.

It’s basically a jQuery widget factory, but organizes event handling code in a very elegant manner.

By: Introducing Pintura | SitePen Blog

Introducing Pintura | SitePen Blog — Fri, 22 Jan 2010 09:44:03 +0000

[...] JavaScript frameworks like Dojo, General Interface, Cappuccino, YUI, and ExtJS that provide client-side MVC. In particular, Dojo has excellent support for standards-based JSON REST interaction that matches [...]

By: Johnny

Johnny — Thu, 05 Nov 2009 15:54:44 +0000

Hi Suman:
MVC deals with, to use a common phrase “loosely coupling” these elements. The model knows nothing about the controller or the view, the controller doesn’t know about the view and the view only knows about either the controller’s dependency on the controller, or the controller itself. then they communicate with events, broadcasted to space but listened and acted upon by the interested components.

I thought about what is the best scheme, to update the controller’s instance of the model or to interact directly with the model. I opted to have the view update the instance of the model rather than the model itself. This is because the model is not a singleton in most cases, and as has been described in many javascript discussions it is best not to create too many of them to avoid future conflicts. Besides, the mvc flow of events is not a perfectly linear process because each component will broadcast its events at any given moment based on interaction by the user on the view or by interaction between components at any given time. Also, not every action to the view will result in a modification to the model, but a mere refresh is more frequently common.

Thanks.

By: suman

suman — Wed, 02 Sep 2009 06:13:35 +0000

Hello Kris,
thanks for a great and insightful blog up there, here is a point i will like to draw your attention to is the following portion from your blog.
In a nutshell my concern is whereas the elegant use of MVC as u have mentioned seems to be (flow of control and data) view –> controller –> model and back the same way . There are some situations where calling the model directly from view makes more immediate sense thus bypassing controller . Do you think that this might break the decoupling we try to achieve in mvc or the pragmatism of bypassing controller just weighs too much on this ?? Let me know ur thoughts.

“..Rather, you can add an event handler for the button that will call the deleteItem method on the store (defined by the dojo data API) for the selected item, which is effectively controller code interacting with the model (the item from the store). The store will then send a notification event to the grid, which will update the view to eliminate the row corresponding to the deleted item…”