Skip to content
magnayn edited this page Sep 14, 2010 · 2 revisions

This is a work-in-progress and should be considered experimental. Many things may not work or be finished!

In the beginning

On building reasonably large Flex applications, we have been through a number of frameworks. Initially, not using a system at all, we migrated to Cairngorm. This generated huge amounts of rather inflexible code. So we looked for an alternative

Then there was mate

We have been happy users of mate for some time. It has a very clever approach, utilising MXML tags to concentrate on the two key areas

  • Injection
  • Event Routing

The automatic injection into views is extremely nice, meaning that the code is very clean and there are minimal dependencies on the actual framework within the code.

However, as our application grew, some problems start to emerge. Firstly, it is quite hard to modularise applications that extensively use popup windows – the LocalEventMap system doesn’t really conveniently make a hierarchy of maps (e.g: some events you want your local window to process, others you want the “parent” window to process). We initially fixed this by making extensions to mate, but it isn’t perfect, and we ended up with quite a few difficult-to-pin down memory leaks because of un-freed event maps.

Secondly, whilst the automatic view injection implementation is nice, it has some problems – particularly there is no easy way to ‘un-inject’. So, for example, if you have a view in a tab control, once it is bound to its manager – it will always re-bind even if it isn’t visible anymore (the user has tabbed away). This can cause lots of unnecessary web service call traffic.

Looking around

There are several good frameworks already in existence, for example: RobotLegs. However, to retro-fit our applications to use the RobotLegs style would require substantial refactoring that would be quite difficult to achieve. Furthermore, these style of frameworks (coming from a mate perspective) still require a lot of unnecessary boilerplate code – the IoC pattern mitigates a lot of the bloat present in cairngorm applications, but seems to ignore the benefits available with flex bindings to automatically connect views and models such as is common in mate.

Ribbons

So we wanted something that

  • was suitable to migrate a big mate application
  • could do all the things that mate could do (eventually)
  • that could be used in small parts without ripping the guts of the application out
  • that was flexible so that special cases could be overridden in code
  • that was declarative in code, rather than config files
Clone this wiki locally