Flex :: Best practices architectures

The best practice for defining components that return information back to the main application is to design the component to dispatch an event that contains the return data. In that way, the main application can define an event listener to handle the event and take the appropriate action. You also use events in data binding. (1)

“Name your components using a different convention. This is not a requirement but it will help out in the long run. On my projects we use all lower case with underscores between the words (ex: my_button) to identify a component in the MXML. Camel case (ex: myVarName) is used for public and protected properties. I am an old school Flash developer so I use a single underscore (ex: _privateVar) for private variables and double underscores (ex: __myGetterSetter) for private properties that are exposed via a getter/setter. By using this kind of naming convention it makes reading your code easier to determine what is being manipulated and when.” (2)

“One of the common goals when you create MXML components is to create configurable and reusable components. For example, you might want to create MXML components that take properties, dispatch events, define new style properties, have custom skins, or use other customizations.” (1)

“One design consideration when you create custom MXML components is reusability. That is, do you create a component that is tightly coupled to your application, or create one that is reusable in multiple applications?” (1)

“A tightly coupled component is written for a specific application, often by making it dependent on the application's structure, variable names, or other details. If you change the application, you might have to modify a tightly coupled component to reflect that change. A tightly coupled component is often difficult to use in another application without rewriting it.” (1)

“You design a loosely coupled component for reuse. A loosely coupled component has a well-defined interface that specifies how to pass information to the component, and how the component passes back results to the application.”

“You typically define the properties of a loosely coupled component to pass information to it. These properties, defined by using implicit accessors (setter and getter methods), specify the data type of the parameter value. In the following example, the CountryComboBox custom component defines a public useShortNames property that exposes the _useShortNames private property using the get useShortNames() and set useShortNames() accessor methods.” (1)

“The Flex code-behind pattern is a design pattern that has been around since the release of Flex 1.0 yet 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.” (2)

“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.” (2)

“When looking at Adobe’s MXML examples we often see them using the <mx:Script> 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 <mx:Script> 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.” (2)

“One way to solve this is to use the source attribute in the <mx:Script> 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.” (2)

“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:” (2)

package com.vivisectingmedia.demo
{
    import mx.containers.Canvas;

    public class MyComponentLogic extends Canvas
    {

    }
}

I have now created a Class in the com.vivisectingmedia.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.vivisectingmedia.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.

Remember that the MXML inherits from the base logic class. What this means is that as you add children components to the MXML and you want the ActionScript Logic to manipulate them you have to make sure the ActionScript has them declared. To declare them you have to define properties in the ActionScript class whose name matches the component id you use in the MXML. For example, look at the Button id in the MXML above and notice that I have a public property in the ActionScript with the same name. The property must be public in the ActionScript class and you should mark them as [Bindable] so that if you have other components binding to them the change watcher system still operates as expected.

This works because the MXML file is an extension of the base logic class and the components with the matching id is equivalent to overriding the properties in the ActionScript. You may wonder why the properties have to be public and not protected if this is an override. The issue is that the MXML components are not part of the MXML class, they are children of the MXML class. Since they are children they do not have access to the ActionScript class’ protected methods and the compiler will see their id as a duplicate name for the MXML class, which is invalid. If the method is public, the compiler interprets this MXML component id as an override and it works. So, long story short… always make the properties [Bindable] public.

Never try to manipulate the children components from the ActionScript constructor. This is a common mistake made by developers using this pattern. For example, you try to set the button label in the constructor. If you tried this you would get a null value error for the button since it has not been created yet. MXML creates the children components in the initialize() phase so the best way to work around this is to override initialize(), call super.initialize() first and then you can start accessing children components.

Never try to removeChildren() that are defined in MXML. This is a mistake that sometimes works when you try it but in most cases this just causes a lot of heartache. Usually the heartache occurs after you have been doing this for a while and you then have to go back and fix a lot of code that was dependent on the first removeChild(). Unfortunately I have seen this first hand and its not a pretty sight. If you are doing a lot of children manipulation then you will want to move away from MXML declaration and handle the children creation/removal all in ActionScript.