Thoughts on ideal Flex framework

I’ve just come to London yesterday and went straight to London Flash Platform User Group meeting. Gilles Guillemin presented Mate Framework (read Mate as “maté”) which is supposed to take over Adobe Cairngorm and PureMVC frameworks and be simpler than those. I personally feel that Mate Framework is not much different from other frameworks just because it’s trying to follow the same idea about Flash event mechanism being the best way to communicate inside any Flex application. But events were invented mainly for visual stuff, with all bubbling, cancelling and stages! That’s certainly true they work great for Flex framework itself but Flex is visual components framework, and frameworks we’re talking about are for so called “client backend” – a layer between visual components of your Flex application and server backend.
So here are my thoughts about the ideal Flex framework. I’ve organized it in action steps/considerations that would help you to create such framework.

12 steps

1. If you can use Adobe Flex framework, use it! You’d better create a component than anything else. You can reuse components later in other projects and The Reuse is the main divinity in software engineer’s pantheon.
2. What is missing in Flex framework is a thin but important layer between Flex components and server side (Java, PHP .Net etc). This is where our ideal framework can be useful.
3. “Write less do more” is the only thing that important about any framework (it should be true in a long run too). Theoretical principles like MVC, patterns etc are not so much important as this one.
4. Dependency injection/Inversion of Control pattern is the next best thing after sliced bread. If you have numerous objects in your application (and you do usually have them), you have to write code to make calls from one object to another (to couple them). Look up code could take up to 1/3 of your total code if you have many small routines. It also makes your code highly coupled and hence not very reusable. So something that could automate lookups is definitely should be in our ideal framework.
5. The framework should help you to work with asynchronous calls. Asynchronous calls are the way how Flash app communicates with server side. Usually you need to add event listener and remove it after you got response from the server. We need to get rid of it and let framework manage it.
6. Also about asynchronous calls, it’s usually needed to chain some asynchronous calls (to make next call only after previous call is executed with success, for example). Or you just want to execute some function after all asynchronous calls are executed (and don’t really care about the order of calls). In this case what you usually do is to write lots of event listeners just to manage this workflow and it becomes a mess very quickly. So our framework should help us with that too.
7. Debugging. Flex Builder (for example) has quite good debugger so our framework shouldn’t break it or have any unpredictable execution flow (which is usually the case when you overuse events)
8. Code auto completion. This is something that we’d like to be able to use too (to avoid all these typing mistakes)
9. Our view classes or MXMLs should be decoupled but not too much. You should be able to take a look at MXML file and see any data dependencies it needs. However, our view classes shouldn’t care about how to get these data.
10. Testability. It should be easy to test you classes using FlexUnit for example. Writing/executing tests seems to be one the most important thing for bug free software.
11. We should use ActionScript3 language and not just copy Java idioms to ActionScript. It means to use functional objects and event listeners where Java uses anonymous classes and interfaces. The framework also should make good use of dynamic typing.
12. Performance: memory and speed. It should be the last point in this list as you need to take care of everything else before optimization. Premature optimization is the root of all evil!

Let’s see how Ctx Flex framework answers to these requirements.

Ctx is dependency injection framework with many features that are essential for creating enterprise applications. It’s similar to Java Spring framework. Ctx has one class called remarkably enouch Ctx. You register any objects with this class using register() method and after this it becomes a bean. Ctx manages dependencies for beans using autowiring by name or type. For details read Ctx “Getting started” and “Reference” documents.

1. Ctx doesn’t add itself to display list or interfere in any way with Flex components. It won’t help you with creating Flex components as Flex framework itself is good enough for this task.

2. Your visual classes use Ctx framework to communicate with server backend. If you don’t have server backend in your application it usually means that you don’t need to use Ctx framework. This makes Ctx framework more enterprise application oriented framework. Ctx sits between Flex visual application and server backend, effectively filling the gap.

3. To get started with Ctx framework, you should know only one class: Ctx. You don’t have to create anything extra to communicate inside your application (no need for copious custom event classes, for example).

4. Ctx does dependency injection for you (autowiring by name and by type). You can adjust many details how dependencies should be wired using metadata, but metadata is not required as Ctx has reasonable defaults and you can use simple naming conventions to enable/disable autowiring, enable autowiring by type or by name, enable automatic dependency creation etc.

5. In Ctx we have a bunch of functions to work with asynchronous calls. Use handle(someAsyncCall(), onResultHanler, onFaultHanler). Use chain() to chain several asynchronous calls, use branch() to execute several calls simultaneously (without any specific order). These functions operate using AsyncToken object (all RPC services return AsyncToken objects). In addition, Ctx framework has artificial implementation of AsyncToken which is useful when you need to do something asynchronously but without backend. This is how mock objects (for testing remote services without actual backend) and multithreading are implemented in Ctx framework. Also it’s quite common to store the result of asynchronous function call somewhere in data model. For this you can use handleData() function. All these functions are package level functions so you don’t have to prefix them with class name (similar to other package level functions like trace() etc).

6. You can link handle(), brach(), chain() functions in the manner similar to functional programming. They all return operate on AsyncToken objects and they return AsyncToken objects. You can add different handlers in different places to AsyncTokens. You can add parameters to tokens to pass some additional data (AsyncToken is dynamic object).

7. Ctx doesn’t use events, only dependency injection. So whenever you see some error, call stack tells you exactly what happened, where and execution flow. (However, you can use Ctx as event bus to broadcast events to multiple beans if needed).

8. Ctx could be used in typeless mode (because Ctx is dynamic object),or you can subclass Ctx and add hardcoded names to all your beans (so FlexBuilder will be able to provide auto completion).

9. You just reference your data model properties in your data model beans (bean is a class that is registered with Ctx class). Something like <mx:List dataProvider=”c.myModelBean.customers” /> You still see what are data dependencies for your view object but it doesn’t have any code to get these data. You can create pair view-model bean and just specify properties inside model beans. These properties could be populated later by some bean which knows how to get data. We use data binding here. “c” is an instance of Ctx which is bindable. Of course, properties in your data model bean should be bindable too. View doesn’t have to wait till framework initialized, it gets notified when data is available via binding mechanism.

10. Your beans are simple AS3 classes. You can test them using FlexUnit for example. If your beans have asynchronous calls, it’s not a problem as FlexUnit has support for asynchronous calls as well.

11. Ctx object is dynamic object. It means you can add properties to it as you will do with any object of type Object. Adding a property has semantic of registering a bean, getting a property is the same as getting wired instance of some bean. Helper functions like handle(), chain() and brach() use closures (functional objects) so you type very little comparing to what you would have to type if using interfaces.

12. Ctx has support for data caching (using CachedService) to optimize memory and network usage, support for quasi-multithreading (to execute extensive processing in AS3).

I’ve never intended Ctx to be used by broad masses of people. But I find many people struggling with the same problems as I did, so I decided to share this framework and I hope it will be useful (at least I can guarantee that it won’t be harmful )