Mate Flex Framework Example

    Mate flex frameworkImmediately after the birth of the above framework, I realized that this is exactly what was missing for so long. I really did not want to break into the bondage of creating a huge number of classes using the Cairngorm or PureMVC frameworks, and with the advent of Mate , it became possible to reduce the overall connectedness of application components and use painless messaging (events) by declaring them in the "native" mxml.

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


    So, I prepared the projectopportunities (so to speak, very promising) on Google Code with available sources . To begin with, consider it on-line : We have a list of entities with the ability to edit each of them in a separate form, and adding new ones is never easier. The following solution, as always seems unreasonably complicated for such an example, but it is unforgettable that we are faced with the task of familiarizing ourselves with Mate , rather than writing an example in 25 lines of an action script. I use the so-called “two-way communication through model and injection” scheme , the framework’s website has an excellent diagram of this and other techniques:









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

    Model


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

    The third is OpportunityDataProvider , designed to work with a specific editable OpportunityVO from the list. It has the public property opportunity , as well as methods for manipulating it. This class dispatches opportunityCreated and opportunitySaved eventssuch as DataProviderEvent, which inform about the completion of the opportunity processing (since these actions are often associated with calling server methods, we cannot expect them to be executed synchronously in the stream of calling class methods). The implementation of the class is very simple, but in reality, it is necessary to put in it all the transformations, initializations and other procedures on the element that are not related to the logic of the presentation, and can quite easily be 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 presentation , the first is OpportunitiesListView to display a list of items. It has one public property dataProvider , and also, it dispatches two createOpportunity and editOpportunity events of type OpportunityEvent, which speak for themselves.

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

    Third - Indexis a composition of the previous ones. The selectedIndex property is available in it , which determines the current visible form.



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

    Mate event maps


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

    One of the cards, the DataInjectionMap , describes the relationship between the view and the model; it runs only once when the application starts. This is a partial implementation of the IoC (Inversion of Control) pattern., which works in an unusual way: if necessary, it only creates instances of model classes and listening to the events of the parent Application, at the time of creating views, it performs the described bindings. Typical notation using Injectors and PropertyInjector tags: Here we define the binding based relationship between OpportunitiesListView and OpportunitiesDataProvider, using the dataProvider property , which data will end up in the DataGrid. The rest: OpportunitiesEventMap , DataProviderEventMap , NavigationEventMap , directly describe the actions that should occur when the Mate (Event Bus) is in the field of view





    any events from both the view and the model classes. For example, the notation using EventHandlers tags, MethodInvoker and EventAnnouncer: This statement reads as follows: at a time when the idea prodispatchit event editOpportunity (in fact, pressing the Edit button), the model class instance OpportunityDataProvider should start operation edit instance OpportunityVO class, which is available from events. Also, a special event NavigationEvent is sent, as a result of which the view should switch to edit mode. Inside the OpportunityDataProvider class, the server method must be called to get an OpportunityVO instance with the last state of the element (but in my example, I simplified the scheme and save it in the property





    opportunity models, the same object). Further, since we specified injection in the DataInjectionMap between OpportunityEditView and OpportunityDataProvider by the opportunity property, the edited item will be available in the view.

    In the generator or source properties of the above tags, we indicate the model class, 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 all kinds of model instances or events, and searches there for the necessary objects for reuse. This pattern is similar to the Singleton pattern., but it is much more practical, since there is no unnecessary binding between system entities that are inevitable when using "loners" (by the way, there is a rather strong drawback of other frameworks like Cairngorm or PureMVC ).

    And finally, consider the specifics of the NavigationEventMap map, which describes the response to NavigationEvent events. In general, switching view modes could be implemented directly in it. But, as practice has shown, in large projects, it is visually easier to 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: When the navigateEditView event hits the Mate , the method is called from the auxiliary class of the OpportunityViewState model, which is proxy. I would not want to introduce this class for these purposes, but would assign values ​​to selectedIndex directly in the index view class, but in the generator property



    MethodInvoker tag (as well as all other tags), you cannot specify the classes of visual components (that is, it is possible, but it will be wrong, since the framework will create an instance 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 falls into the display list of the player’s flash, the framework starts “cooperating with it” "(Often for determining ( 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 intersect.

    That's all. Information on all available framework tags can be found indocumentation on the Mate website . I hope the description did not work out too confusing. I will be happy to answer all the relevant questions on the topic.

    PS By the way, the other day there was an update of Mate to version 0.8.7 , in which it became possible to set the connection ( injection ) between the interfaces.

    Also popular now: