Mate Flex Framework usage example

Immediately after the birth of the above framework, I realized that this was exactly what was missing for so long. Caryngorm or PureMVC did not want to get into the bondage of creating a huge number of classes, but with the arrival of Mate , it became possible to reduce the overall connectedness of application components and use painless messaging (events) declaring them in the native mxml.

Some colleagues constantly strive to find out all the details and nuances of using Mate in practice and therefore I decided to describe an example of a typical architectural solution based on a model of a real application. It is similar to the examples from the framework site, but is described step by step with specific recommendations at all levels.


So, I prepared the project of opportunities (so to speak, promising) on Google Code with the available sources . To begin, consider it online :
')


We have a list of entities with the ability to edit each of them in a separate form, as well as add new ones - it doesn't get any easier. The following solution, as always, seems unreasonably difficult for such an example, but it is unforgettable that we are faced with the task of becoming familiar with Mate , rather than writing an example in 25 lines of an action script.

I use the so-called “two-way communication using the model and injection” scheme , on the framework website there is an excellent diagram of this and other techniques:



Consider each element of the diagram based on the classes in my example. Point 3 is excluded, because for access to the server we use a special class of service OpportunitiesMockService inherited from ServiceBase .

Model

I identified three classes of the model. The most elementary view-dependent class of the OpportunityVO list item. The second class, OpportunitiesDataProvider , is a list of OpportunityVO instances, it encapsulates calls to server methods and, for convenience, is inherited from ArrayCollection. This makes it possible to use it as a data provider for most of the list components from the Flex framework.

The third - OpportunityDataProvider , is designed to work with a specific editable OpportunityVO from the list. It has the public property of opportunity , as well as methods for manipulating it. This class dispatches the opportunityCreated and opportunitySaved events of the DataProviderEvent type, which inform about the end of the processing of opportunity (since these actions are often associated with calling server-side methods, we cannot expect them to run synchronously in the class method call flow). The implementation of the class is very simple, but in reality, it is necessary to put all transformations, initializations and other procedures on an element that are not related to the logic of the presentation, and can be quite successfully separated from it.



There is also an auxiliary class OpportunityViewState , which is used to store information about the current visible form in the view. Such classes have to be created to solve the communication nuances of Mate , then I will describe them in detail.

View

Three classes are also defined for the view, the first is an OpportunitiesListView for showing a list of items. It has one public dataProvider property, and it dispatches two createOpportunity and editOpportunity events of type OpportunityEvent, which speak for themselves.

The second OpportunityEditView class is defined by the property of the opportunity in which you need to assign the OpportunityVO editing object directly, as well as the other two saveOpportunity events and the closeOpportunity also of the OpportunityEvent type.

The third - Index , is a composition of the previous ones. In it, the selectedIndex property is available, which defines the current visible form.



This is our presentation. As you can see, its classes are inherited from the standard Flex framework containers, they have no dependencies on the data providers of the model, are passive and look like rather self-sufficient components for reuse - what we need.

Mate Event Maps

We turn directly to the role of Mate in linking the model and the view. All the declarations of this framework are described in the so-called “event maps” . These are MXML files that support binding and all the other conveniences of Flex Builder . As the project grows, these cards expand quite strongly, so for different groups of communications I get separate files. In this example, there are four.

One of the maps, DataInjectionMap , describes the links between the view and the model; it is executed only once when the application is launched. This is a partial implementation of the IoC pattern (Inversion of Control) , which works in an unusual way: if necessary, it creates only instances of the model classes and listening to the events of the parent Application, when creating views, performs the described bindings. Typical notation using Injectors and PropertyInjector tags:

 <Injectors target="{OpportunitiesListView}"> <PropertyInjector targetKey="dataProvider" source="{OpportunitiesDataProvider}" /> </Injectors> 

Here we set the connection based on the binding between the OpportunitiesListView and the OpportunitiesDataProvider, through the dataProvider property, the data of which will end up in the DataGrid.

The rest: OpportunitiesEventMap , DataProviderEventMap , NavigationEventMap , directly describe the actions that should take place when the Mate (Event Bus) is in view of any events from both the view and the classes of the model. For example, notation using the tags EventHandlers, MethodInvoker and EventAnnouncer:

 <EventHandlers type="{OpportunityEvent.EDIT_OPPORTUNITY}"> <MethodInvoker generator="{OpportunityDataProvider}" method="editOpportunity" arguments="{[event.data]}"/> <EventAnnouncer type="{NavigationEvent.NAVIGATE_EDIT_VIEW}" generator="{NavigationEvent}"/> </EventHandlers> 

This expression reads like this: at that moment when the view proves the editOpportunity event (essentially pressing the Edit button), an instance of the OpportunityDataProvider model class should start editing the instance of the OpportunityVO class, which is accessible from the event.

Also, a special event NavigationEvent is sent, as a result of which the view should switch to edit mode. Inside the class OpportunityDataProvider, the server method should be called to get an instance of OpportunityVO with the last state of the element (but in my example, I simplified the scheme, and save the same object as the model property). Further, since we specified the binding in the DataInjectionMap between the OpportunityEditView and the OpportunityDataProvider on the opportunity property, the editable element will be available in the view.

In the generator or source properties of the above tags, we indicate the class of the model, not an instance of this class. Mate will automatically create an instance at the right time, and, by default, only once. The framework has an internal cache for various instances of the model or events, and searches there for the necessary objects for reuse. This scheme is similar to the Singleton pattern, but it is much more practical, since there is no unnecessary binding between the entities of the system, which are inevitable when using "singles" (by the way, a rather strong lack of other frameworks like Cairngorm or PureMVC ).

And finally, consider the specifics of the NavigationEventMap map, which describes the response actions to the NavigationEvent events. In general, the switching of presentation modes could be implemented directly in it. But, as practice has shown, in large projects, it is easier to visually control the approach of external control of the presentation. For example, if you need to connect deep-linking (support for changing the address bar of the browser), we will introduce another type of BrowserNavigationEvent events that will use ready-made action lists in Mate maps. So, the notation:

 <EventHandlers type="{NavigationEvent.NAVIGATE_EDIT_VIEW}"> <MethodInvoker generator="{OpportunityViewState}" method="setSelectedIndex" arguments="{[1]}" /> </EventHandlers> 

When the navigateEditView event gets into Mate , the method of the auxiliary class of the OpportunityViewState model is called, which is proxying. I would not like to enter this class for this purpose, but would assign values ​​to selectedIndex directly in the Index view class, but in the generator property of the MethodInvoker tag (like all other tags), you cannot specify classes of visual components (that is, you can, but will be wrong, as the framework will create an instance that is inaccessible to anyone). The bottom line is that, as I wrote above, Mate does not create instances of visual components (and does not try, MXML does it), it listens to the events of the entire application, and when the component gets into the display list of the flash player, the framework starts to cooperate "(Often to determine ( injection ) dependencies). It turns out that there is an internal cache of all created classes by the framework itself and a separate list of components that the flash player manages and they do not overlap with each other.

That's all. Information on all available framework tags can be found in the documentation on the Mate website. I hope the description did not work too confusing. I am pleased to answer all the relevant questions on the topic.

PS By the way, the other day there was a Mate update to version 0.8.7 , in which the opportunity to set connections (interfaces) between interfaces appeared.