MVC vs Data Driven

MVC. Data driven. Components. Hierarchical composition. Reuse. Confused?
Me too. Lets do some untangling.

Big, brave, open-source, non-profit, community-provisioned, cross-cultural and dingbats crazy. → Like, share, back-link, pin, tweet and mail. Hashtags? For the crowdfunding: #VisualFutureOfMusic. For the future live platform: #WorldMusicInstrumentsAndTheory. Or simply register as a potential crowdfunder..

Many Views Onto a Domain or Problem Space.

MVC Model-View-Controller

Model View Controller (from Wikipedia)

Aside from routing, one of the major benefits claimed by many web development frameworks is the ability to exploit MVC.

This separates three interrelated aspects of GUI structure:
o how something is represented (View) on the screen - above all the possibility to select between multiple views
o the data (Model) used to generate it
o the effect of user actions on data access and use (Controller).

I'm no specialist in MVC, but alone the fact that what are essentially mappings should be necessary suggests some kind of compromise. In fact, MVC appears to be trailing a rats tail of complication and bloat.

Data Driven

This project takes a different, data driven path, whereby:

o standard classification indexing is used as a means of structuring data repositories, which, as it allows physical addressing, renders routing, and hence the Controller superfluous.

o data elements are identified using selectors and filters specific to the desired, but highly configurable view, rendering the Model superfluous. The model is inherent to the manner in which we manipulate our data.

In fact, all that is left is the data (hence 'data-driven') and it's appearance, or View. Combined with a hierarchical composition of interface elements, it ensures that every musical use case is covered by a dedicated and fully configurable animation. We have, effectively, no use for MVC...

--> Cleaner, faster, simpler.
--> Prototype in the Browser

One Model, Many Views

Multiple Views

There are areas in which more or less standard (of off-the-shelf) data visualisations can be put to use (in our case, for example, to explore relationships among users, groups, instruments, events and location).

It will, moreover, be possible to derive a small range of different utility, instrument model or theory tool views from the same base data.

For instruments, this would be the case where, say, radically different chromatic accordion or concertina keyboard layouts share the same classification index and cover the same basic range of notes or tones.

Icosahedron

Even a simple configuration tree (our base navigation data) can have a variety of views: the normal vertical layout, scaled vertical, the radial tree, scaled radial and so on.

Amongst theory tools, we often have a choice between 2D and 3D representations: circle of 5ths vs conical spiral, flat tonnetz vs torus or  and so on.

Moreover, simple experiment is going to suggest alternative, new -and in some situations preferable- views, again beyond the scope of the classification system.

Reusable Components

Finally, a footnote concerning React.js, (looked apon as the "V" in MVC and used to build large applications with data that changes over time). So far, I've identified no scenario that couldn't be handled with plain javascript in a generic-to-specific graphical hierarchy (though it would be a different matter if these components were to be reused on other platforms). Plain and simple, I have the feeling it replicates part of the compromise inherent in MVC as a whole.

Potential Crowdfunder? First Name Email Address

On the other hand, combining D3 with React allows the creation of externally reusable chart components.

Their respective component lifecycles show strong similarity. D3 has enter, update and exit, and React has componentWillUpdate, componentDidUpdate and componentWillUnmount, enabling their lifecycles to be mapped directly to each other.

D3s and React work together well to structure code and build reusable UI components. React encourages structuring of components to enforce a top down data flow, meaning that though lower level components can receive data and render it, they never independently manipulate data that might affect higher-level components.

In our case, however, data flow is from external GUI components (JSON configuration data, menus, shared radar configuration charts etc). These often address low level components, causing higher-level dependencies to be automatically updated.

If, for example, I update the temperament or intonation of a lute-like instrument, this has impact on the fret positioning, and hence the fretboard roadmap as a whole. There is, in this respect, a natural component update workflow.

It's difficult for me to say if the bottom-up implementation of the music aggregator platform can be successfully combined with the top-down approach of react.js.

Clearly this is an area for continued trial and error. My feeling is, however, that if the MVC paradigm is to be adopted, then it should be under data driven terms and conditions..

---

Keywords

---

online music learning, online music lessons	distance music learning, distance music lessons	remote music lessons, remote music learning
p2p music lessons, p2p music learning	music visualisation music visualization	musical instrument models interactive music instrument models
music theory tools musical theory	p2p music interworking p2p musical interworking	comparative musicology ethnomusicology
world music international music	folk music traditional music	P2P musical interworking, Peer-to-peer musical interworking
WebGL, Web3D, WebVR, WebAR	Virtual Reality, Augmented or Mixed Reality	Artificial Intelligence, Machine Learning
Scalar Vector Graphics, SVG	3D Cascading Style Sheets, CSS3D	X3Dom, XML3D