Cairngorm Event Flow

This is the first tab of the Console main window:

In this screenshot, we see the following elements:
• On the left side there is the main event list
• On the right side, you will find an object inspector to look inside relevant data of the selected event
• At the bottom, you will find a text area containing the stacktrace for the selected operation

For more information about this view, please refer to the reference guide

Cairngorm operations

The main list displays the sequence of what we call "cairngorm operations", ie actions that occur within Cairngorm, that are generally triggered by the program itself, responding to a user gesture.
The table below provides a description of all cairngorm operations defined in the console, and its relevant data that can be inspected, in alphabetic order:

Analysis of the flow

Received event are numbered from 1 to n. If the console has been instanciated early, as indicated in the integration guide, you should also see all initialization events.
If we examine the event list displayed upon startup in the demo application, we can make the following analysis:

• 1,2: The first two events are internal to the console itself and may be ignored

• 3: Initialization of the main FrontController, the stack trace panel indicates that it occurred in the CafeTownsend.mxml source file, at line 59. This is actually the line where the FrontController is instanciated, through a line of MXML:

  	<control:AppController id="appController" />

• 4,5: Registration of command "LoadEmployeesCommand" and associatied with event named "LOAD_EMPLOYEE_EVENT". Here, we can see how Cairngorm works for managing command: it first add an event listener for the CairngormEvent that will trigger the command, then it registers the command class into the FrontController. The stacktrace indicates that this operation was started in the CafeTownsend.mxml source file, at line 59.

• 6-19: Registration of other commands of the application through the same mechanism

• 20: Creation of a new HTTPService, triggered from Services.mxml:6 <- CafeTownsend.mxml:57.

  <business:Services id="services" />

  Feel free to inspect the service object in the inspector panel, and to check out the url and other parameters.

• 21-22: Execution of the LoadEmployeesCommand. Here again, we see how Cairngorm works, by first dispatching a command event (LOAD_EMPLOYEE_EVENT) at CairngormEventDispatcher level, then executing the command itself.
  The starting point is at CafeTownsend.mxml, line 46 which is called upon creationComplete event of the application:

  private function loadEmployees() : void {				
     var cgEvent : LoadEmployeesEvent = new LoadEmployeesEvent();
     CairngormEventDispatcher.getInstance().dispatchEvent(cgEvent);
  }
  

  The first line of the stack trace is the same for these two operations, as we filter out non significant entries from the stack trace, in order to always have the application code source line at first, instead of internal framework sourceline, and be forced to read many tedious lines of log to find out the interesting line. Here, if the CairngormEvent is custom and contains public attributes to be used as parameters by the command, you will be able to inspect them in the right panel.

• 23: Registration of a new service, triggered by the command at LoadEmployeesDelegate:14 <- LoadEmployeesCommand.as:16. In the source code, we see that the command creates a new Delegate object, that in turns gets an HTTPService from the ServiceLocator. As this is the first time that this service is used, it is registered (only once) in the ServiceLocator.

  public function LoadEmployeesDelegate( command : IResponder ) {
    // constructor will store a reference to the service we're going to call
    this.service = ServiceLocator.getInstance().getHTTPService( 'loadEmployeesService' );
    // and store a reference to the command that created this delegate
    this.command = command;
  }
  

• 24: Service send operation, that sends an HTTP request through the above HTTPService, happenend at LoadEmployeesDelegate.as:21. We may also inspect the service parameters and discover that the url for this call is "assets/Employee.xml"

  public function loadEmployeesService() : void {
    // call the service
    var token:AsyncToken = service.send();
    // notify this command when the service call completes
    token.addResponder( command );
  }
  

• 25: Service result, the service has returned successfully, its execution time is displayed in the list, and the results may be inspected. In the right panel, we discover that the service returned an ArrayCollection named "employees", containing 4 entries. Entries are of ObjectProxy class and contain employees information that we can also inspect. This is the result of Flex framework XML decoding process, that creates ArrayCollection and ObjectProxy instances.

By this simple analysis, we have been able to discover all the initialization process of the demo application, knowing what commands has been registered, and what have been the first initialization commands dispatched.

Activity monitoring

When you use the application and its features, you are also able to follow and watch what is happening in real time.
To do so, just move and resize the console so that it leaves you enough room for the application, and leave the event flow tab visible.
Login into the application, and play around with it ; while doing this, you will see that the operation list is refreshing in real time, always displaying the last operation (generally at the end of the list, unless you decided to sort it in another order). In business and typical Cairngorm applications, there will likely be dozens of operations recorded in short time, and hundreds or thousands of them after a slight period of use.

In order to facilitate navigation and search, you will use the following tools:

• Event filter: the upper combo allows you to display only operations of a given type. Note that the filters will only display operation names that have occurred at least one time. For example, if no Service fault has ever occurred, you will not see it in the filter combo list.
• Play/pause button: if you pause the console, no new operations will be recorded nor displayed.
• Clear button: deletes all recorded operations, hence freezing retained objects that were referenced by the operations records.

Next >> ModelLocator