Mate – The Good, the Bad and the Ugly

Lately, the new Mate flex framework by asfusion has caused quite a stir in the flex community, as a contender to the established frameworks of Cairngorm and PureMVC. Most of the comments on Mate that I have seen has been quite positive, which I think is well deserved. Mate offers a new way of doing things, when compared to Cairngorm and PureMVC.

In my opinion, there are downsides to Mate, and I think one needs to consider these too, before blundering out in a new flex framework.

So, on with “Il buono, il brutto, il cattivo”.

The Good

Here are the main benefits I see in Mate.

1. AcknowledgesÂ Its Flex Heritage

Mate is a flex framework, meaning it does not try to hide or abstract access to flex apis. It uses normal flex events as communication mechanism, and depends heavily on the flex apis in general. This is something it shares with Cairngorm, but stand in clear contrast to PureMVC. PureMVC has gone to great lengths, to abstract out any access to the flex apis, in the process inventing its own event-like system in the form of “notifications”. This makes the PureMVC framework itself portable to other platforms, but only puts extra burden on the developer, which have chosen flex as the platform.

2. Builds Upon Dependency Injection

Mate utilize dependency injection (DI), which is a programming pattern I have come to like, and use day in and day out, when doing Java development. Using DI promotes louse coupling between classes and subsystems and makes for a more flexible codebase. What DI in Mate should give me, is mxml and application logic, which does not depend directly on the Mate apis. I like that.

3. Simple, Uncluttered View

Using Mate, the mxml view definitions become really simple an uncluttered with anything but the view code. This is partly due to the above description on dependency injection, as Mate is able to inject into the view, when it needs data. This is something Mate shares with PureMVC, but not with Cairngorm. PureMVC also makes for pretty simple mxml view definitions, but at a higher cost, using Mediators and extra levels of abstraction.

The Bad

That was some of the main benefits, I have seen with Mate. Now on to what I do not like about Mate.

1. Too Much Magic

In short: There seems to be too much magic happening behind the scenes. Now, I should be a little careful here, because this might be due to me not knowing the intricate details of the framework yet. On the other hand, I recal previous experiences with Tapestry v3+4, where in-depth knowledge of how the server-side playback of a request works inside Tapestry, was needed to understand how to use stuff like ActionLinks. Maybe some of it can be taken care of with better documentation, maybe not. My main point is, that you should be able to use the framework, without knowing intricate details about how it works beneath.

So, where is the magic? It is in the EventMap, where one wires up the whole application with various xml tags. And we shall get to that right now in the next section.

2. Programming in XML

Mate has something called an EventMap, a place where one wires up the application. You can think of it, as the place where flex events from the UI is mapped to application logic, but also where processing code and remote calls execute and return results and data back to the view.

The EventMap is all done in XML, and is where the dependency injection is defined, as in which UI components get which things injected as a result of what. What I do not like about the EventMap is how it looks like application code, … just in XML. Take a look at this example:

Which is something like when a FlexEvent.APPLICATION_COMPLETE event is fired, the application shall call some remote service (the HTTPServiceInvoker part), and the result of that shall be parsed by an instance of EmployeeParser through its method loadEmployeesFromXML,….

Shit, I thought I would never have to see something like Jelly again. Programming in XML quickly leaves you up shit creek without a paddle. I hate that!

3. Nullifies The Power of AS3 Compile-Time Type Checking

Okay, granted, I do not think it completely nullifies all type-checking. But the xml EventMap is not understood by the compiler, as the mxml code is, hence no type-checking will be done by the compiler on that part.

As an example, when data-binding a property of a component to some other property or variable using an expression like fooProperty={bar}, the mxml-compiler will generate as3 code which does the binding, and the generated code includes type-information, that will make the compilation fail, if the types do not match.

Not so with all the “code” in the EventMaps.

The Ugly

And on to the ugly part. This is mostly for fun, as I happened to peak into the code of Mate and saw this:

13 Responses

I disagree on your “magic” point. Mate is a framework and therefore implying that it should somehow be understandable within 5 minutes doesn’t seem fair.

Also, you don’t have to use the HTTPServiceInvoker stuff if you don’t like coding in the XML. It’s your choice based on your project. You could use nothing but MethodInvoker and be able to easily imitate Cairngorm’s Command and PureMVC’s Command and Mediator.

If you want to use the deeper stuff, it’s your choice. It’s not complex at all. Learning a little more about Mate will pay off in spades.

cease - September 11, 2008

Can you provide a write up of which flex framework you like the best, and maybe more comparisons between the three. I’ve been struggling to figure out which framework is the best at this point. I’ve heard nothing but complaints out of the cairngorm. I have been hearing a lot of good things about mate, actually this is one of the first, I read with negatives. Also puremvc, from a java developer standpoint seems to make sense.. but seems to be the biggest beast to handle out of the 3. thanks

You are right, in that one should expect more than 5 minutes, until the framework has been understood. And as I also wrote, I might be wrong here. Still, one should only have to know the concepts on how the framework works, and hereby be able to use it. One should not have to know the intricate details, to be able to use it. If you tell me, that once I know Mate better, all will be clear, I trust you to be right. I have not found the EventMap xml to be intuitive yet.

But, when you write:

Also, you donâ€™t have to use the HTTPServiceInvoker stuff if you donâ€™t like coding in the XML. Itâ€™s your choice based on your project. You could use nothing but MethodInvoker and be able to easily imitate Cairngormâ€™s Command and PureMVCâ€™s Command and Mediator.

somehow I just knew that comment would come in. And it is a valid one, cause you are right, I could just make the EventMap a simple dispatcher to some real as3 code.

BUT: The EventMap is a very important part and concept of Mate. A large part of the framework is centered around the EventMap. It is thought of to be the place to use for this. This is the intention of the framework. If one is to start using Mate, one should also buy into the concept of the EventMap. It is an important area of Mate, where it think it helps you. And it might. I just doubt it.

I would love to do a writeup, but it is time consuming, and I am not sure I have that time currently. I might come out with something about puremvc soon, as I have been using it for some time now, and surely has something to say about it.

I think Cairngorm has it’s faults but I find that most criticisms are generally based an OOP-purist arguments and not based on how the framework fails to serve it’s purpose in the real world. For example, there is a lot of talk about it’s incompatibility with unit testing as it’s so easy to reference ModelLocator in every component. But you don’t have to do that – a smarter way is to only reference ModelLocator in your top-level views (which in my case are modules) and inject the model, or pieces of it, down the line into lower-level components.

My other issue with Cairngorm was the lack of a good event notification system for views but the Universal Mind Extensions for Cairngorm seem to help with this and other issues.

Lastly, you might like to use Mediators to keep your views ‘dumb’. This isn’t prescribed by the Cairngorm framework but it’s easy to implement.

[...] the common problems are and how to solve them. I pretty much share the dislike of coding in XML blogged by Olesen and discussed on InfoQ. Another review of Mate is done by Flash Magazine and the structure is [...]

boulder_lingie - September 26, 2008

Interesting post. I like puremvc (the framework suits me, and I like the community support & excellent docs). Mate has me interested, though, because it seems like it might be easier / quicker to use.

Desagree with you in the point 2
that way is MXML way instead of XML is a tricky word
and this make diferences in Flex project and Flash project
that way is more easy way to Developers which came from HTML and js way