360Flex - Laura Arguello on Scaling the Mate Flex Framework

Laura starts by discussing some of the exchanges with users in the past year since Mate's release. Specifically, she says they often asked how Mate would scale since most of the examples were of small applications. This presentation will cover how Mate can work in large and complex applications.

Laura shows a sample application that they built for this presentation. The application was something like a private intranet with contacts that can be viewed and managed, depending on your permissions. The initial code she shows uses no framework and each view contains business logic and remote object calls. She discusses how this is not maintainable and not reusable. This, she says, is the problem that every application framework tries to solve.

She then shows how Mate tries to address this problem discussing common Mate concepts such as the EventMap and dependency injection. For instance, she shows a modified view that has all the relationships removed, whereby the values it displays are handled via injection. Next she shows the Manager code which serves as the model for this view as well as containing the business logic. She says you can also separate the business logic from the data, but you end up with a lot of classes and the "command" class handling the logic also needs a relationship to the model and causes too many relationships.

She mentions creating events with multiple related functionality rather than a separate event for everything. However, you need to be careful of creating monolithic events that carry "unrelated payload," meaning it has data that doesn't necessarily relate to each other.

Next she covers the EventMap. She discusses how you can have more than one EventMap and you should separate them into related functionality. As with the events, you do not want to have your EventMap get too large to become unmanageable.

The problem is that solving these problems becomes more complex when your application gets big, regardless of what framework you use. She says this isn't a Mate specific problem. She recommends using the "presentation pattern" to help solve these issues. She takes the code from the prior example and breaks it down to show all the issues that the view code solves and try to show how to remove some of this complexity into a "presentation model" class.

Specifically, this class contains most of the script logic from the view along with some extra constants and methods to handle the state. The data required will now be injected into this class rather than the view class. While the class is specific to the particular view, it does not contain a reference to the view. One other change this class requires is a change to the event dispatching because this is not a UI element and the events would not bubble; she creates a private method that handles dispatching events with IEventDispatcher. She then shows how to use this class within the specific view it relates to. Finally, she shows how to write the unit test for this presentation model.

She moves on to discuss using modules. She says modules can be a beast to manage so you have to be careful. She then converts the contacts section of her application into a module with its own EventMap and Manager class. The problem is that you need to create a smaller event bus rather than the global event bus that is typical. This specific event bus will only handle events that are related to its module. You change the EventMap to use a LocalEventMap tag which is a different class.

This also makes the instance of the manager for that EventMap local, as in another EventMap in your application would now get a different instance rather than the same one via the cache. In order to access global elements, like information from other Managers (in this example, it needs the currently logged in user). This can be handled via the PropertyInjector property called sourceCache which can be set to "global." You also need to set another property called "softBinding" which should be set to true, thereby removing the bindings when the module is unloaded.

She also shows how to go the other way using an interface that the module would implement. Once done, you can use the interface as the target for your property injector inside your main event map whereby the property is automatically injected into any module that implements this interface. In this case, she injects the currently logged in use to all the modules.

Lastly, she shows how to handle module to module communication using an EventAnnouncer with the dispatherType property set to "global." In the other module, you would add the EventHandler with the dispatherType also set to "global." She says she will post the sample application on the ASFusion site by the end of the week.