Discitur Project

As promised in the first sprint, I would have dealt with this topic as soon as I could. The second sprint now seems to be overestimated for what I need to implement and the first sprint was closed faster than expected; therefore it is the right opportunity to develop certain design aspects. And then, after the TDD, I wanted to take some time to try and insert UI-Router. The thing was very quick and easy. Reverse engineer the app and tests for removing angular -route and put in UI-Router is a step without much difficulty. One of those steps that will help to increase your appreciation about Angular and its extensibility. As expected, UI-Router has everything I needed:

• possibility to nest views dynamically
• ability to dynamically resolve views in parallel
• ability to manage the routing in a more logical way
• good documentation  

One of the interesting things (and which I will give later a refactoring) is the abstract views. These are views that can not be instantiated by themselves, but they expect some descendant views that implement them. They seem to make a very good concept of the masterpage, or container of one or more pages that have the sole role of wire-frame and define the layout of views. This is an important aspect for me; in fact, this concept allows the single view not to worry too much about the routing rules or what’s around it. If structured properly (I mean the interfaces defined in terms of events for communication with other VC) the single isolated pair VC can safely be developed independently by a programmer or a development team.

By now I structured my app as follows:

thus separating the html pages that are the application masterpages from angular modules (which therefore have individual features). The scaffold routing rules (or rather, the state machine) is made at two levels.

 

Level 1: MasterPages (abstract states)

This level is defined in the configuration of the web application and define what kind of layout is provided in the site navigation. These configurations do not define the actual routing rules, because all states are defined as abstract and therefore can not be solved by the UI-Router StateManager without some other implementation. Here’s the interesting part of the code:

 

Level 2: Content-Pages (“phisical” states)

This level is the one that defines the set of states of the application, and then define routing rules. Each module has its own routing rules and its own states, which must implement one of the states defined in the abstract master pages.

 

For example. for the “static” site, I defined the main module as follows:

 

As you can see the parent used (by choice) is always ‘master.1cl’ to indicate that the static application pages are always mono-column.

As for the Lesson module, some states are as follows:

 

With a 2-column layout (parent: ‘master.2cl’). The single internal feature (eg. The ‘LessonNewsCtrl’, which will probably take a different name for the next refactoring) was developed without keeping in mind any aspect related to the application wireframe.

I find it very modular and easy.