Architecture (The M Project 1.x)

General Overview of an Application Workflow

The following sequence diagram describes the way of adding a todo item to the application (see Todo Example). Persistence is left out in the diagram.

1. The workflow starts with the user entering a text into the textfield and pressing the 'Return'-Button on the (virtual) keyboard. By the frameworks convention, all events have to pass the EventDispatcher class. We reach this by binding certain events (here: the keyPress Event) to handlers for elements matching a certain (jQuery) selector (inputelements, for example, match this selector). The handler calls the eventDidHappen method of the EventDispatcher.

2. Internally, delegateEvent is called with some information of the Event object as parameters:

   • type: defines the type of event, e.g. 'click' or 'keyPress'
   • id: the value of the html attribute id of the element that fired the event, in our case the textfield's id.
   • keyCode: optional parameter describing the pressed keyboard key.

   By getting the id of the element, thanks to the ViewManager, it is possible to get the view object that rendered the element (means the element's object representation). By getting the view object we also get the target and action property of the object that have been defined when designing the view. In this example we get TodosController as our target and addTodo as action. We call it.

3. Because we want to create a new todo item, we create a new object of the corresponding model: Note. We also pass it a text (that, in practice, we got from the textfield object's value). Next we add the returned note to the controllers ModelManager. The ModelManager is a class that manages a collection of models for a controller. Then we set the controller property todos (which defines the collection of todo items) to the modelManagers modelList (which includes all models created in our application yet).

4. Now, Magic happens. Because the ListView inside this application was designed to observe a property inside the controller (in detail: the controller's todo collection, that we set the step before), it is supposed to underlie changes, of which it doesn't know till notified: The controller knows its observers and knows when an observed property of itself changed. When setting controller values with the controller's own set method, the controller iterates over all its observers and notifies all observers that observe the changed property via the contentDidChange method that is defined in the view. In our example, the ListView receives the content change call and starts to render the update. Via Content Binding the view has access to the todo list. After completion of the rendering it returns to the controller.

5. In our application we always want to show the correct number of todo items in the todo list. To achieve this, the label that represents this number observes another property of the TodoController: the number of items inside the todo list. Now when an item has been added to the list, calculateCounter is called to reflect the changes in the item list on the number of items property. Inside this call, again a set call is made and the procedure, described in the step before, is repeated. But this time it's not the list that renders the update (because it doesn't observe the number of items property) but the LabelView.