Frontend architecture
The UI of Concert is fairly complex, which is why steps have been taken to ensure that the code is very modular, extensible, and maintainable. Backbone.js powers all of the UI, and thus the components of the interface have been separated into an MVC architecture.
The basic entities that comprise the UI architecture in Concert are Models, Pages, Panels, Widgets, and Components. Here is how they are related graphically:
->
->Overview of UI entities (full size).<-
The models on the Frontend are fairly straightforward, but there are a few caveats. In order to ensure that no model instances are duplicated, we maintain a seenInstances object which contains the instances of every model instance we have come across. Before any model is instantiated, seenInstances is checked first to see if there is already an instance, and if so, we use that one instead of creating it again.
Here are the different types of Models we represent on the Frontend:
->
->Model class hierarchy (full size).<-
The Page object is the first object to be instantiated on load. This is a Backbone.Controller subclass that will handle the interaction between many components on the UI.
Panels are divided sections on the UI that serve a particular purpose, such as displaying a list of audio files or displaying a waveform.
Widgets are small sections of the user interface, usually contained within Panels. Widgets are data-driven, and for this reason are typically duplicated many times.
A Component is a member of a Panel, much like a Widget, but is not data driven, and is instead something like a playhead, which will typically not be duplicated.
The organize page is the heart of the application, and is where the users go to organize their audio files/segments. Below is a diagram that shows basic relationships between the different Page, Panel, Widget and Component instances on the organize page. It is a work in progress ;)
->
->Organize page UI classes (full size)<-