Model Action View

[I am still deciding to call it MAV, or MRAWV (Model Relation Action Widget View). The later is more accurate, but doesn't sounds any better.]

This MAV pattern gives a few advantage over MVC.

The controller-less pattern is more restrictive but allows better encapsulation, composability and reusablity (ECR).

ECR is possible because the patterns greatly simplified the message flow each component responsible for. Coupled with jQuery events binding, each components is self-contained, receives a single set of message and send messages to a single sink type.

When a widget is initialized, it binds itself to the known model. It also bind itself to any jQuery object events.

From the model, a widget receives well defined CRUD-like events. From the DOM, it receives well defined widget events (click, mouseover, change etc).

It is completely reactive, making it easy to write and predictable.

View is defined as a collection of widgets.


This pattern also adopts a strict convention from "Action" and "Model", and from "Model" to listener. It enables common (perhap open source) component to be use with model, especially on quasi-typed language (read: javascript).

Notice that a model can be chained to a upstream model. An upstream model can be either a superset of equal set of the downstream model.

The beauty of the design is that the upstream model can be located remotely. They can be connected with HTTP server over RESTful service.

While "Representational State Transfer" is elegant, having no way to conceptualize a state change sucks big time (for lack some of better words.)

It makes much more sense to call
   picture.tag("Expo 2010");
   if (picture.tags !== undefined) pictures.tags = []; pictures.tags.push("Expo 2010");

MVA patterns allows both Action and Model to be resides on a remote server from the widgets.

Does it work?
I am able to build a 6000 lines "mobapp 2.0" app without violating the pattern. It is not entirely easy in situation where some components want to talk to multiple model. I worked around it by introducing the concept of Relation, in which Relation is a model holding entries with pairs of ids.

So far so good.