AdvancED Flex 4

TURBO-CHARGING DATA BINDING

71

</fx:Script>

<s:Label id="simpleText"/>

</s:Application>

This technique will come in very handy. You simply created a new instance of your CustomerVO object and

are able to listen to changes to all properties in this custom object with very little code.

Flex Data Binding Pitfalls and Common Misuse

Mistakes

Data binding is one of the most used processes when building Flex applications, but at the same time, it’s a

costly process and can delay initialization of an application. It’s a good idea to pay attention and ensure it’s

used correctly and when needed. I compiled a list of five common pitfalls and incorrect misuses that

developers do when building a Flex application while using the binding process.

Using Bindable When Binding Is Not Necessary

The use of unnecessary binding tags occurs when you bind a property that can be done easily without the

binding tag. In cases where you don’t need to bind, and you can do it with direct assignment, then it’s best to

avoid binding. I have seen this type of mistake many times in many shapes and forms. Take a look at the

following code which illustrates one example:

<?xml version="1.0" encoding="utf-8"?>

<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"

xmlns:s="library://ns.adobe.com/flex/spark"

xmlns:mx="library://ns.adobe.com/flex/mx"

minWidth="1024" minHeight="768">

<fx:Script>

<![CDATA[

private var text:String;

]]>

</fx:Script>

<s:layout>

<s:VerticalLayout />

</s:layout>

<s:TextInput id="textInput2" text="{text}" />

</s:Application>

You have a text input with a text property binding to the text variable. Looks harmless enough, right? I have

seen this type of tags often in Flex applications and I must admit that I have placed a few of these in the past

myself. The mxmlc generates code to allow the binding. You will find that although you don’t need to bind the

text String, because this is a one-time assignment, the mxmlc still generates code to accommodate binding of

the property.

CHAPTER 2

72

In this case, you can do direct assignment of the value:

<s:TextInput id="textInput2" text="text" />

By using direct assignment, you are saving the mxmlc compiler from having to create extra binding code and

significantly reducing your overheads.

Using the Wrong Bindable Event Name

Using the wrong event name in the bindable tag can cause your application to refuse binding your property

and you won’t even know why. When you use the bindable tag with a custom name, the following example

looks like a good idea.

public static const EVENT_CHANGED_CONST:String = "eventChangedConst";

private var _number:Number = 0;

[Bindable(event=EVENT_CHANGED_CONST)]

public function get number():Number

{

return _number;

}

public function set number(value:Number) : void

{

_number = value;

dispatchEvent(new Event(EVENT_CHANGED_CONST));

}

You are assigning a static property to the event name so then you can use the same assignment to dispatch

the event. However, when the value changes the binding tag doesn’t recognize the change. The reason is that

the event name will be EVENT_CHANGED_CONST and not the value of the variable.

Assuming Execution Order of Binding

A common mistake when binding is assuming that a binding order is in synchronous execution order and will

cause your application to generate a warning and not bind your property. Events in ActionScript are executed

in an asynchronous manner. Take a look at the following code:

<?xml version="1.0" encoding="utf-8"?>

<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"

xmlns:s="library://ns.adobe.com/flex/spark"

xmlns:mx="library://ns.adobe.com/flex/mx"

minWidth="1024" minHeight="768" creationComplete="creationCompleteHandler(event)">

<fx:Script>

<![CDATA[

import mx.events.FlexEvent;

[Bindable]

public var buttonText:String = "Execution order mistake ";

]]>

</fx:Script>

TURBO-CHARGING DATA BINDING

73

<s:layout>

<s:HorizontalLayout />

</s:layout>

<s:Label id="simpleText" text="{buttonText}" />

<s:Button label="{simpleText.text}" />

</s:Application>

Although the code may work, you are assuming that the simpleText text property was already set since the

value of text is binding and not the actual text property. You also get a compile time warning, as shown in

Figure 2-9.

Figure 2-9. Compile time warning showing in Problems window

Here’s another example where you assume that the value of the first TextInput was already set. Also, this

type of assignment generates all the code to create binding from the mxmlc compiler. You have to consider if

it’s worth it or if direct assignment (y="35") is a better choice.

<?xml version="1.0" encoding="utf-8"?>

<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"

xmlns:s="library://ns.adobe.com/flex/spark"

xmlns:mx="library://ns.adobe.com/flex/mx"

minWidth="1024" minHeight="768">

<s:TextInput id="textInput1" x="10" y="0" />

<s:TextInput id="textInput2" x="0" y="{textInput1.x+25}" />

</s:Application>

Assigning a Binding Tag When You Don’t Need It

There are many cases where you can write your code easily without data binding and use a ChangeWatcher

or events to assign a value. It’s recommended to avoid binding when it’s not needed. Consider the following

code:

<?xml version="1.0" encoding="utf-8"?>