Recap: In Part 1, I discussed the basic implementation and use of the ModelLocator pattern. This pattern is one of many design patterns contained within the Cairngorm micro-architechture. This design pattern will be used in Part 2 as well, so it is assumed that you are familiar with the concepts in Part 1 of the tutorial. At this point, we still are not working with a "complete" Cairngorm application (that will come in Part 3).
Part 2 - Using a ModelLocator to Manage the View
Note: As with all of the tutorials that will come in this series, this lesson has two parts. First, in the article you will learn the theory behind the topic, and then in the video you will do an actual "code-along". The article will give some instructions in how to set up your project for the "code-along".
In the previous tutorial you learned the advantages of using a ModelLocator to manage data within an application, however, the advantage of the ModelLocator pattern extends beyond the management of data. It can manage the "view" of an application as well. To see how view management works in Cairngorm, you will first need to create a new project named "ViewManager" and name the main application file "Main.mxml". For this project, your will also need to add the Cairngorm.swc to your project build path (as described in Part 1). You will also need to create two new folders inside of the "src" folder: view and model. When you are completed, your project should look similar to Figure 1 below.
Figure 1 - ViewManager Project
Next, you will need to take the ModelLocator code from the previous tutorial and place it inside your application. I have posted the code below for your convenience.
Example 1 - The ModelLocator from Part 1
If you need information about the ModelLocator, please return to Part 1 of the tutorial.
The only item that must be changed in the ModelLocator is the "package" statement. For this project, you will be placing the ModelLocator in the "model" folder, so the package path simply needs to me "model" (it has already been corrected above). You will also need to add one variable to your ModelLocator initially. This variable will be called "workflowState" and it will be of type "uint". The declaration will look like this:
Example 2 - Defining the workflowState Variable
This variable will be used to "control" the view in your application. The most common way to accomplish this is to use a ViewStack [ Reference ]. If you are not familiar with a ViewStack, feel free to read through this information. A ViewStack has a property named "selectedIndex". This numeric value defines which "child" is visible in the ViewStack. Consider the following code:
Example 3 - A Basic ViewStack Example
Initially the value of selectedIndex is 0. With this setting "box1" would be visible. If you issue the following command:
Example 4 - Manually Setting the selectedIndex
then the box named "box2" would be visible. However, if you apply the ModelLocator to this concept, you could use the workflowState varaible to set the selectedIndex property. By binding the selectedIndex to the workflowState value, you now have complete control over what is displayed in the ViewStack from your ModelLocator.
Example 5 - Binding the selectedIndex to the workflowState
Defining Constants for Better Code
It would be simple to manipulate the view using this method, however, it could lead to potentially confusing code. For example, assume that you have the following:
This might seem as if it works properly, but it doesn't account for any changes. If another child is added to the ViewStack, it could throw off the order. There needs to be a better way to manually set the selectedIndex property. To accomplish this you just need to define constants inside of the ModelLocator.
Example 6 - Defining View Constants in the ModelLocator
By using this method, you only have to change the value in one location if the number of children or the order of the children changes in the ViewStack. Now, you would assign the login button the following action to the click event:
Example 7 - Setting the View with Defined Constants
Not only do you protect against future changes, you also have made your code much more logical. Another developer could easily look at the code and understand the process without having to reference all of the children in the ViewStack.
NOTE: The audio was not that great for this video. I will be using a better system for the next tutorial.
Video Example - Controlling the View with a ModelLocator
Download (3 kB)