Separation Of Concerns (SoC) is crucial when writing large applications, especially if we consider the development of complex GUIs.
SoC guarantees the flexibility and testability of your apps and introduces best practices around architectural patterns, such as MVC or SOA.
What is WOOZ?
- It uses WAXML, instead of HTML, as presentation language (WAXML is freely inspired of the Flex MXML language).
- It comes with a robust MVC framework, based upon Dependency Injection (DI) and Inversion of Control (IoC).
- It is no compiled, but interpreted by browsers.
SoC in WOOZ
WOOZ has been designed with SoC in mind and the following diagram shows how the framework articulates the separation between the different layers of an application:
If we consider the Core API as the central point of the application, we can separate layers as explained below:
- On the left-hand side, we have components responsible for managing user inputs. All user GUI components, including Views, extend classes provided by the WOOZ GUI API.
- User classes, displayed on the right-hand side, define the logic of the application. They are managed by the Twister framework, which organises the different behaviours by implementing the MVC architecture.
Understanding The Twister MVC Framework
The particularity of the Twister framework is to take benefits of IoC and DI to implement the MVC architecture in WOOZ applications. Thus, it uses containers for managing both, the MVC and the Service Oriented Architecture (SOA) components.
Each container has its own context, defined in a context file, where developers can make their assemblies. (You can find some context file samples on the WOOZ website).
Context files provide a greater flexibility regarding reusability, testability and weak-coupling (e.g. using mocks) of an application.
The Event-Driven Paradigm
Actually, as it reproduces the same model as Flex, the WOOZ framework is built over an event-driven architecture. It means that all MVC and GUI components are both event producers and event consumers.
So, you can extend an existing application in a flexible and non-invasive manner. This mechanism introduces an easy way to build loosely-coupled applications by using the MVC loop:
The MVC loop provides a convenient way for developers to focus only on what a specific part of an application has to do, in response of a notification, independently of what the other parts are doing. Most of actions and events follow the same cycle: the view notifies the controller which notifies the model which notifies the view. All other interactions, specified by the MVC pattern, must be used only when the MVC loop cannot be applied to an unusual case.
This is particularly easy to do in WOOZ because of its event-driven model, combined to the injection of MVC objects in the views.
Event-Driven Model vs. Dirty Checking
Dirty checking is the cycle during which AngularJs checks if there are any changes to all the variables watched by all the
$scopeObjects. This mechanism is used by AngularJs to perform data binding. On the contrary, WOOZ uses events notifications to implement data binding.
Both paradigms do exactly the same, but the Event-Driven Model has the major advantage to provide a much more fine granularity.
Moreover, data binding process in WOOZ does not break the MVC loop; thus, views updates can be declared in WAXML tags, by using the curly braces syntax. The following sample shows how the source of an image can be updated depending of the model state:
In any cases, AngularJs must traverse all of the model to notify changes, while WOOZ will immediately find the component to update.
Model and Services
The Twister framework has been designed to implement the Resource Access Architecture (RAA).
RAA consists in providing client-side components, associated to Data Transfer Objects (DTO), that represents a distant resource. The components responsible for accessing the resources are called Resource Access Services (RAS). RAS could be compared to Data Access Objects (DAO), defined in a in server-side architecture. They are parts of the model and are typically consumed by the model objects that manage the state of the application.
By clearly separating data from the way to access them, Twister truly increases the flexibility in terms of development.