incredipixel.com blog

I finished refactoring the Precog Pandas project using Mate today and I have to say that Mate is pretty nice. In this post I’ll just go over a few of the things I learned along the way and talk about the things I liked/disliked about the framework.

You can download the Mate version of the project if you’d like to look through the code.

Tags

Mate is a tag based framework, which makes your code more concise and easier to read. I’m used to working with XML config documents with frameworks, i.e.: the ModelGlue.xml config file, so working with tags to define event handlers and such seemed very natural to me.

Where I got stuck is how do you debug things when you’re working with a tag instead of an AS class? For example, if you want to see what exactly is getting passed into your HTTPServiceInvoker, where do you set the break point? I learned from the Mate documentation that you can add a Debugger tag to your event maps and turn on debugging within your different EventHandlers, which exposes some information to you within the console window when you run the project in debug mode. However it seems more like a logging tool versus a debugging tool since it just reports back that a particular event handler ran, etc. In the end it didn’t pose much of a problem, but it seems like you trade a little bit of the granular control you get with AS classes for the simplicity of defining things with tags.

Event Maps

Events maps are cool. I like that you can fire off all sorts of things from one event handler. It’s very easy to define an event handler that retrieves some data, updates your model, and then injects the updated values from your model into your view.

Contrary to what I said earlier about the limitations of using tags, I actually appreciate the fact that the event maps are designed around tags since it forces you to keep things simple. After all, the event map represents your controller, and controllers should really just facilitate communication between your models and views, not contain your business logic.

However, I did get stuck again when I was trying to determine how I would fire off the getPhotos event once the list of pandas had come back. Since I loop over each panda to send out the getPhotos event, I needed some logic in there. Since I couldn’t put the logic into the event map, it went into the model. Unfortunately, it seemed that I couldn’t fire events from my model without making some modifications. I learned from this post and then this post that I just had to include the Mate GlobalDispatcher so that my events being dispatched from the model would be picked up by my event map.

Dependancy Injection

Very cool. I define bindable public vars in my views, and like magic my event map populates them for me. No framework specific code in my views.

Managers

The Mate examples suggest setting up a “Manager” that can act as your model and/or contain business logic. I’ve seen the “Manager” pattern described elsewhere and it usually relates closely to the Facade pattern. A Facade basically provides a simplified interface (API) to a collection of objects that make up the domain of your application. The Mate sample applications generally show the business logic being dropped right into the Manager, but of course there is no reason why you can’t abstract your Manager out into separate objects/concerns.

Overall Impressions

I think Mate’s strengths lie in it’s simplicity. It doesn’t dictate how you organize your domain model, but facilitates the interaction between your model, views, and controller. It doesn’t force you into using particular patterns or restrict how you choose to design most of your application. It also supports modular application development so the framework doesn’t weigh you down as your application grows.

I really like Mate and I think it is ideal for the types of applications I typically work with. Next up I’ll be looking at PureMVC. Check out all the posts in this series.