Adobe Flex : The Code-Behind Pattern

The Flex code-behind pattern is a design pattern that is not known or used by a lot of developers. The initial concept of the pattern was based on the ASP.NET development pattern where the layout is handled in a main file and a secondary “backing” file handles all the logic. The goal of the pattern is to create a clear separation of logic and layout.

When you first learn Flex there is often confusion between what MXML is and how it relates to ActionScript. We tend to think of it as different entities, but the reality is MXML is just an abstracted form of ActionScript. MXML is a declarative XML syntax that is converted by the compiler into an ActionScript class. This is an important concept to understand because this is the root of why the compiler throws an error when trying to have a MXML file and an ActionScript File with the same name in the same package. The MXML file is really just an ActionScript class and therefore we have a conflicting namespace error.

To help visualize this, imagine the root node of the MXML file is the same as an extends statement.

When we use something like this in MyApp.mxml:

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
 ...
</mx:Application>

We are really saying:

public class MyApp extends Application

So why do we need an MXML syntax if it just becomes ActionScript. As you are probably well aware, doing complex layout in ActionScript takes a ton of code, especially when you get into the world of nested layout. It can be done in code but why would you want to? XML is all about parent/child hierarchies and by using this as a layout language you can quickly define complex organizational structures that would have taken hundreds of lines of code if you did it all in ActionScript. Now that we have a better understanding of the MXML/ActionScript relationship we can start talking about how the pattern is implemented.

When looking at Adobe’s MXML examples we often see them using the tag to define any ActionScript that is required to make the MXML example work. This approach is fine for simple examples but once we begin development of a larger application using Flex, having all the MXML logic in a single tag becomes unwieldy. Even if the code is written by the most organized developer, once you hit 300+ lines of ActionScript with 100 lines of MXML it becomes hard to see the forest from the trees.

One way to solve this is to use the source attribute in the tag and set it to an external AS file. This helps because you now have separated all your ActionScript out of the MXML but now you have externalized AS files that aren’t really classes, that sit in the file structure and you can’t extend from them.

The Code-Behind pattern is a solution to this issue. The first step is to create an ActionScript class that extends the base type that you want your MXML file to be. For example, a Canvas:

package com.hello.demo
{
 import mx.containers.Canvas;
 
 public class MyComponentLogic extends Canvas
 {
 
 }
}

I have now created a Class in the com.hello.demo package that extends from Canvas. This is my backing logic class that my MXML extends from. Note that I have used the postfix “Logic” to create a unique name. If you recall, our MXML and AS have to be different names. I prefer the “Logic” postfix but you can use “Base” or “Backing” or any other postfix/prefix you like. Now, you can create the MXML file. In this example let’s assume the MXML component is in the same package as the ActionScript:

<MyComponentLogic
  xmlns="com.hello.demo.*"
 xmlns:mx="http://www.adobe.com/2006/mxml">
 ...
</MyComponentLogic>

This code would be in an MXML file called MyComponent.mxml. The MXML now extends from the ActionScript and we can begin to start laying out content and adding logic as needed.

Some alternatives to the technique I describe here, is to use the Supervising Controller pattern or the ViewHelper. However, a sidenote to the Supervising Controller is that you should probably choose to call the classes for ...Presenter instead if ...Controller as the use of Controller seems to put some people of if they are not familiar with this pattern and leading them to think they are FlowControllers or ApplicationControllers. Read more about the Supervising Controller pattern at Martin Fowler's excellent website... http://martinfowler.com/eaaDev/SupervisingPresenter.html