Mate, an unobtrusive Flex application framework

If you are tired of application frameworks that tie your code together and makes it an unwieldy mess, take a look at Mate.

Mate is quite unintrusive, lets you configure your application declaratively in MXML and does most of the boring things for you. Judging from the documentation and examples it looks like good competitor in the less-than-crowded marked of Flex application frameworks.

The core of Mate is something called the event map which describes what should happen when your application dispatched events of different types. For each event one or more handlers can be invoked. A handler can be everything from calling a method on an object, running a command or invoking a remote object call and there is room for writing your own specialised handlers. Handlers can also run in sequence and get hold of the previous handler’s result, which makes it possible to create quite complex logic. All this is done in MXML, which means that your configuration is also the actual wiring of your application — and it’s readable and quite easy to understand.

My only objection is how Mate handles updating of views. If I understand it correctly, there are two ways, either you have an injector which looks up the view and pushes values into it, or you have an instance of a dispatcher in your view where you listen for result events and update accordingly. Both remove the benefits of bindings, and while they are certainly better than the global variable lookup of other Flex frameworks, I’m not sure I like them. On the other hand I think you can skip that part and inject the model into the views directly. On the third hand, injectors can potentially make your code more decoupled.

Update: see comments below for a clarification on this issue by the framework’s author.

17 Responses to “Mate, an unobtrusive Flex application framework”

  1. Kapil Viren Ahuja Says:

    Either the link you have provided is incorrect or the site is down

  2. Theo Says:

    I really doubt that me writing about it would have any /. effect, but it really looks like the site has gone down since this morning.

  3. Nahuel Says:

    Hi Theo, Thank you so much for your comments. I just wanted to point out that the injectors are binding the model with the view if the source is bindable (extending from EventDispatcher). The difference is that we don’t have a reference from the view to the model as in model.getInstance(). Instead, we bind the properties that we want from outside the view using the injectors. In addition, sometimes we use a Model Adapter when the view is more complicated and it needs “massaged” data instead of the raw data. In this second option, the adapter is injected and the view binds to the adapter. An example of this is in the weather widget example ( The code there can be simplified by using public variables, but we wanted to make our Model Manager a bit more explicit and only let other components get the data but not be able to set it.

    By the way, the site is up again now. 

  4. Theo Says:

    Good to know, thanks for the clarification. I did have a hard time understanding exactly what was going on, because the framework is heavily event driven there is quite a lot of indirection and that makes it hard to follow the code. It’s not a bad thing though, it makes for a more decoupled architecture, but it does get harder to understand.

    I was also a bit confused why and how the injectors reference the views by their class, I can’t find how the lookup is being done, where the mapping of that class to actual instances take place. Perhaps you could clarify that too? (Perhaps this is a question for your forum, but as long as I have your attention…)

    Your Model Adapter sounds a lot like the Presentation Model pattern which I have begun to use a lot, I think it’s a very good fit in a Flex architecture.

  5. Nahuel Says:

    The injectors are mapping to classes because we don’t want to have a direct reference to the views. The views can be instantiated very late in the application or may never be created and the injectors are just waiting there just in case they are created. Or you can create multiple instances of the same view and the injectors will get notified for each. That’s why we use classes, because we want a notification for all the instances that are created from that class at any time in the application.

    Mate by default notifies they injectors every time that a view fire the “creationComplete” event. As you may know this event is triggered only once after the view is ready. The injectors get a reference of that instantiated view and bind the properties via the injector tag. You can also add other actions inside the injectors that can do others things if you need, for example keep a reference to that view or register for events in that view, etc.

    As I mentioned, by default, we listen for the “creationComplete” event, but you can overwrite that with the InjectorsSettings tag (this tag applies changes globally to all the injectors). For example, you can listen for “initialize” or any other event, even a custom event. In addition you can turn “autoWire” to false and they won’t listen for anything. If “autoWire” is false, you will need to register the views by hand. When registering by hand, you also have the ability to pass a unique identifier (useful when you have multiple instances of the same view), but that is another chapter :) As you can see, you can have a lot of control of how the views are injected, but I think that 70% of the people will not need to go deep, so we made the default behavior simple for them.

  6. Theo Says:

    Again, thanks for the clarification. I didn’t realise that you set up the bindings behind the scenes when the views were created, I thought you somehow kept track of the views and pushed the new data in (which would be “bindings” too, just not the Flex framework’s bindings). Now it makes perfect sense that you use the class instead of instance references.

  7. bjorn Says:

    Mate looks very interesting. Especially the view/model binding architechture looks like it could work very well (compared to Cairngorm, which is what I’ve used before).

    Thanks for the tip Theo! This must have passed my flex-framework radar somehow :-)

  8. Tom Says:

    You talk about the ability to have multiple instances of same view with different injectors. Where is this ‘other chapter’ you reference to?

  9. Theo Says:

    @Tom: I think the Mate forums is what you’re looking for!

  10. Tom Says:

    Thanks ^^

  11. enginer Says:

    I hear: “By the way, Mate’s SWC file is now only 60KB. Thanks to a suggestion from Theo, we were able to remove the Flex framework dependencies that were included in the SWC and that were not really needed. Theo explains a bit more in the forums.”

    Can you describe how achieve that?

  12. Theo Says:

    @enginer mxmlc [...] -external-library-path+=path/to/framework.swc [...]

  13. enginer Says:

    plase the framework.swc in the project root anf add “additional compiler arguments” in Flex Builder 3: -external-library-path+=framework.swc -locale en_US … and size .swc of my library do not change(532K) :( In my library I extends the mx classes… as well as flexlib for example, but flexlib.swc is 290K :)

  14. Theo Says:

    @engineer there’s a longer discussion on the Mate forums:

  15. 行骏-IT Player » Blog Archive » 推荐60+ Flex开发参考网站 Says:

    [...] Mate, an unobtrusive Flex application framework – [...]

  16. Bookmark: 60+ Adobe Flex reference websites « Blog Says:

    [...] Mate, an unobtrusive Flex application framework – [...]

  17. Bookmark: 60+ Adobe Flex reference websites | Financial Information For Better Life Says:

    [...] Application Samples – Mate: Event driven framework for Flex – Mate, an unobtrusive Flex application framework – [...]

Leave a Reply