HexMVC javascript

HexMVC implemented in javascript.

by Andy Bulka

HTML

<select id="list" size="10" style="width: 15em"></select><br/>
<button id="plusBtn">  +  </button>
<button id="minusBtn">  -  </button>

JavaScript

/*

HexMVC says that there must be a view class that looks after the off the shelf GUI widget (or in the case of the browser, the DOM element).  In the wild, the term “view” is ambiguous and sometimes means the gui adapter or the gui or both.  I use the term view adapter for the class that looks after the widget/DOM element.

So far this is not controversial.  HexMVC then goes on to say a few more interesting things:

Firstly, that models and GUI widgets should be treated on an equal footing, and be “adapted”. 

Secondly, that generic, application eventing should occur between adapters and a central controller - any private eventing between the gui and its adapter should remain private. In the case of model adapters, they implement all the eventing and the models remain pure.  

Lastly, the application and controller are bound together as the “application hub”, which may be split into many command objects. The application layer talks to the orbiting sattelite functionality via the adapter interfaces, and thus the application is insulated from changes in the “implementation”.  Adapters can, more efficiently, also talk to each other directly, but again, only through the adapter interfaces.

More broadly, the HexMVC approach is wired up through dependency injection and eventing and as you may have noticed, the use of adapters - more specifically families of adapters - so that different implementations can be plugged in without the application noticing.  An adapter is essentially a ‘driver’ you install for a particular implementation being used - like a new printer driver for a new printer.  That’s where the ‘hex’ comes into it, from the ‘hexagonal’ architecture pattern idea (later renamed “ports and adapters”).

Rules and Roles:
----------------
Note: when I say ‘notifies’ I mean via notifications via eventing - which is managed/wired up by dependency injection - and not through layers actually knowing about each other.

 * view layer notifies controller, model...