Migrating Flex Applications
This document describes some of the issues you may encounter as you upgrade from Flex 1.0 Updater 2 to Flex 1.5. For a list of new features in Flex 1.5, please see the Flex 1.5 Release Notes. For installation instructions, please see the Flex 1.5 Installation Guide.
This document contains the following information about the migration process:
Features modified in Flex 1.5
The following functional areas have feature changes in Flex 1.5:- Component layout changes
- Data processing and validation changes
- Style changes
- Custom component changes
- Miscellaneous changes
Component layout changes
The following component layout changes were made in Flex 1.5:- Component sizing rules have changed
- A means for getting percentage width and height values has been added
- Parent container sizing rules have changed
- Navigator container sizing rules have changed
- The resizeToContent property has been added added for backwards compatibility in navigator containers
- The width/height and widthFlex/heightFlex precedence has changed
Component sizing rules have changed
You can now set the width
and height
properties to percentage values. The specified percentage value is a request to span that percentage of the parent container's height or width. You can mix and match components with percentage width and height values, components with pixel width and height values, and components with no specified width and height.
If space isn't available to accommodate all of the requested widths and heights, space is allocated to components with no width and height specified and those with fixed-pixel values first, and then the remaining space is allocated to resizable components in proportion to the requested percentages.
For example, if the preferredWidth
value of the third button is 100 pixels, the following code yields buttons with widths of 130 pixels, 150 pixels, and 100 pixels, respectively (20 pixels are reserved by the margins and gaps):
<mx:HBox width="400" marginLeft="5" marginRight="5" horizontalGap="5" > <mx:Button label="Label 1" width="50%" /> <mx:Button label="Label 2" width="150" /> <mx:Button label="Label 3" /> </mx:HBox>
These percentage values replace the widthFlex
and heightFlex
properties in Flex 1.5. Using the widthFlex
and heightFlex
properties generates warnings, but the application works as intended. If either the width
or height
property is defined with percentage values, the widthFlex
and heightFlex
properties are ignored entirely.
For more information, see "Sizing Components" in the Using Flex Components chapter of Developing Flex Applications.
A means for getting percentage width and height values has been added
Even though they accept either pixel values or percentage values as input, the width
and height
properties always return the current size in pixels. Flex 1.5 introduces two new properties, percentWidth
and percentHeight
, that return the percentage values set in width
and height
, respectively. If the width
or height
property is not set to a percentage value, the corresponding percentWidth
or percentHeight
value is undefined.
The following example illustrates how the width
and percentWidth
properties relate to each other:
<mx:Application xmlns:mx="http://www.macromedia.com/2003/mxml" width="400" height="400" > <mx:VBox width="100%" height="100%"> <mx:TextInput id="txt" text="Stuff goes here" width="50%"/> <mx:Label text="{txt.width}"/> <mx:Label text="{txt.percentWidth}"/> </mx:VBox> </mx:Application>
For more information, see the UIObject class in Flex ActionScript and MXML Reference.
Parent container sizing rules have changed
Parent containers no longer resize to fill their parent automatically if they contain a resizable child. You must set the width
and height
properties (in percentages) on the parent container to make it resizable. Parent containers will still resize to fit their children if no width
and height
values are specified.
For example, in the old parent container sizing rules you would expect the TabNavigator container in the following example to span the entire application window (barring space needed for margins), but in Flex 1.5 it only consumes the space needed to display its contents:
<mx:Application xmlns:mx="http://www.macromedia.com/2003/mxml" > <mx:VBox > <mx:TabNavigator clipContent="true" width="100%" height="100%"> <mx:Tile label="First Tab" > <mx:TextInput text="Stuff goes here" /> </mx:Tile> </mx:TabNavigator> </mx:VBox> </mx:Application>
You must explicitly make the VBox container resizable before the TabNavigator container will span the entire application, as the following example shows:
<mx:Application xmlns:mx="http://www.macromedia.com/2003/mxml" > <mx:VBox width="100%" height="100%"> <mx:TabNavigator clipContent="true" width="100%" height="100%"> <mx:Tile label="First Tab" > <mx:TextInput text="Stuff goes here" /> </mx:Tile> </mx:TabNavigator> </mx:VBox> </mx:Application>
Macromedia strongly recommends explicitly setting the height
and width
properties of every container that contains resizable children. Layout may be unpredictable if you do not set these properties.
For more information, see "Controlling component sizing and positioning" in the Introducing Containers chapter of Developing Flex Applications.
Navigator container sizing rules have changed
In Flex 1.0, if you did not explicitly set the width
or height
property for the Accordion, TabNavigator, and ViewStack containers, the sizing rules calculated the size of the navigator container to be the size of its largest child. If the widthFlex
or heightFlex
properties were set, Flex 1.0 resized the navigator container when you changed child views. By default in Flex 1.5, Flex determines the size of the navigator container by the size of its first child only, regardless of whether the children are resizable. Set resizeToContent="true"
to force Flex 1.5 to resize navigator containers when you move from one child to another.
In Flex 1.0, the following sample code would size the Accordion container to 200 x 200 pixels. In Flex 1.5, Flex takes the size of the first child and sizes the Accordion container to 100 x 100 pixels.
<mx:Accordion> <mx:HBox label="panel 1" width="100" height="100"/> <mx:HBox label="panel 2" width="200" height="200"/> </mx:Accordion>
To make the Accordion maintain the same size as it did in Flex 1.0, add height="200"
and width="200"
to the <mx:Accordion>
tag.
For more information, see the Using Navigator Containers chapter of Developing Flex Applications.
The resizeToContent property has been added added for backwards compatibility in navigator containers
The resizeToContent
property allows you to set the Accordion, TabNavigator, and ViewStack containers to a 1.0 compatible mode. In this mode, entered when the resizeToContent
property is set to true
, these containers resize as you switch child views.
For example, under the default Flex 1.5 layout rules, the following example sizes the Accordion container to the size of its first child and remains at that size; the second child panel needs scrollbars, while the third child panel has excess whitespace after the text.
<mx:Application xmlns:mx="http://www.macromedia.com/2003/mxml"> <mx:Accordion> <mx:VBox label="Panel 1" width="400" height="50"> <mx:Label text="This is Panel 1. Panel 1 has a fixed width of 400 pixels."/> </mx:VBox> <mx:VBox label="Panel 2" width="100%" height="50"> <mx:Label text="This is Panel 2. Panel 2 has a flexible width of up to 100% of its parent Accordion container."/> </mx:VBox> <mx:VBox label="Panel 3" height="50"> <mx:Label text="This is Panel 3. Panel 3 has no width specified."/> </mx:VBox> </mx:Accordion> </mx:Application>
The same example with the resizeToContent
property set to true allows the Accordion container to resize as you switch between the children. No scroll bars are needed in the second panel and the third panel no longer has excess whitespace after the text:
<mx:Application xmlns:mx="http://www.macromedia.com/2003/mxml"> <mx:Accordion resizeToContent="true"> <mx:VBox label="Panel 1" width="400" height="50"> <mx:Label text="This is Panel 1. Panel 1 has a fixed width of 400 pixels."/> </mx:VBox> <mx:VBox label="Panel 2" width="100%" height="50"> <mx:Label text="This is Panel 2. Panel 2 has a flexible width of up to 100% of its parent Accordion container."/> </mx:VBox> <mx:VBox label="Panel 3" height="50"> <mx:Label text="This is Panel 3. Panel 3 has no width specified."/> </mx:VBox> </mx:Accordion> </mx:Application>
For more information, see the Using Navigator Containers chapter of Developing Flex Applications.
The width/height and widthFlex/heightFlex precedence has changed
In Flex 1.0, the width
and height
properties took precedence over the widthFlex
and heightFlex
properties. That is, if both sets of properties were specified for a single component, that component sized to the width
and height
specified rather than flexing as indicated by the widthFlex
and heightFlex
properties.
In Flex 1.5, the widthFlex
and heightFlex
properties take precedence over the width
and height
properties. That is, if both sets of properties are specified for a single component, that component flexes as indicated by the widthFlex
and heightFlex
properties rather than sizing to the specified width
and height
.
Note: This only applies to applications that have not upgraded to use the new percentage sizing support. You cannot mix the old widthFlex
and heightFlex
properties with the new percentage sizing. If you do, the widthFlex
and heightFlex
properties are ignored.
Data processing and validation changes
The following data processing and validation changes were made in Flex 1.5:
- RemoteObject objects only support the AMF protocol
- XML deserialization now respects data type
- Web services enforces inclusion of required properties
- Custom authentication in remote objects supported with the AMF protocol
- The ActionScript data type conversion to Java data types has changed
- The RemoteObject class load classes with the web application classloader
- The suggested way to register client-side classes to server-side Java classes has changed
- The means of handling session data has changed
- RemoteObject objects support by-reference serialization
- The mechanism for using flashvars variables in the JSP Tag Library has changed
- The rules for validating empty data strings have changed
- A NumberValidator validator error code has changed
RemoteObject objects only support the AMF protocol
In Flex 1.5, RemoteObject objects only support the AMF protocol. In Flex 1.0, they also support SOAP.
The encoding
property has been deprecated because there is no longer any need to specify whether to use AMF or SOAP. If you try to use the encoding
property, you will get the following deprecation message:
"The encoding attribute is deprecated. 'AMF' is now the only supported encoding."
For more information, see "Working with remote object services" in the Data Services chapter of Developing Flex Applications.
XML deserialization now respects data type
In Flex 1.0, the HTTPService and WebService data processing logic turned numbers and "true" or "false" into strings when there was no type information in the XML received. In Flex 1.5, if the data type is not explicitly specified in the XML, any number with a nonzero first digit is turned into a number and "true" and "false" are turned into Boolean values.
This means that if statements will now recognize "true" and "false" as true and false logical values, rather than consider them as string values.
For example, in Flex 1.0 you might use the following if statement:
if (valuefromXML=="true"){ // do stuff }
if (valuefromXML){ // do stuff }
This change also affects how data is sorted inside a DataGrid control and other places that automatically sort data. Numerical values now sort as numbers instead of strings.
For more information, see "Handling data service results" in the Data Services chapter of Developing Flex Applications.
Web services enforces inclusion of required properties
A WSDL defines which parameters are expected for a web service method call. Before version 1.5, Flex checked the parameter list and only passed through parameters in the request that matched parameters that were defined in the WSDL but didn't give any indication when the two didn't match.
Now, if a parameter is defined in the WSDL as required but not passed in the request, Flex throws the following error:
"WebService Error - Invalid parameter 'someParameter' not found in input arguments".
Flex also throws an error if there is an unexpected parameter in the request. In this case, Flex throws the following error:
"WebService Error - Unexpected parameter 'someParameter' found in input arguments.".
A required parameter in a WSDL could look like the following:
<s:element name="varInt" type="s:int" minOccurs="1" /> <s:element name="varInt" type="s:int" />
Since the minOccurs
attribute has a default value of 1, these two declarations are functionally identical.
For more information on web services and WSDL, see "Working with web services" in the Data Services chapter of Developing Flex Applications.
Custom authentication in remote objects supported with the AMF protocol
In Flex 1.0, custom authentication was only supported for remote objects using the SOAP protocol, but you can now use custom authentication with the AMF protocol. Flex no longer supports the SOAP protocol for remote objects. This document only describes migration from SOAP.
With SOAP, you had to set up a resource-contraint in the web.xml file for the resource, or use the filter from the samples (which have been removed in Flex 1.5). In Flex 1.5, you should remove all references to the named service in the web.xml file. The roles that were set up in the web.xml file are now set up in the flex-config.xml file inside the named object, as the following example shows:
<object name="SampleSalaryRO"> <source>examples.SalaryManager</source> <use-custom-authentication>true</use-custom-authentication> <roles> <role>sampleusers</role> </roles> </object>
In addition, if you have the encoding
property set on the object, you should remove it.
With these changes, custom authentication of RemoteObject objects should work for most application servers. The supported application servers are JRun 4, BEA WebLogic Server 7 and 8, IBM Websphere 4 and 5, and Oracle 10g. If you are using Tomcat 4 or Tomcat 5, you will also need to follow the instructions in the readme file found in the resources/security/TomcatLogin directory of your Flex installation.
If you are using any other application server, you need to write a custom login command. For more information on this, see the resources/security/CustomLoginCommand directory of your Flex installation.
For more information, see "Securing data services" in the Data Services chapter of Developing Flex Applications and the example in the resources/security/examples directory of your Flex installation.
The ActionScript data type conversion to Java data types has changed
Flex 1.5 has the following improvements with respect to how ActionScript objects map to Java:
- Member variables that are serialized as null are now handled more carefully by the gateway when sending complex ActionScript objects to Java. If the field is a primitive data type (such as int, char, and boolean) and a null value was sent from the client, the property is initialized to the default value for that primitive. For instance, numbers are initialized to 0, Boolean values to false, and chars to the null char '\u0000'.
However, you still cannot pass null to a Java method that is expecting individual primitive arguments such as
public Object get(int index);
- When sending numbers, strings and boolean values from ActionScript to Java, the gateway handles these data types more leniently than in Flex 1.0, in an effort to mimic the autocasting features of ActionScript. Numbers and boolean values can be converted to strings and strings can be converted to numbers or boolean values.
For more information, see "Converting data from ActionScript to Java" in the Data Services chapter of Developing Flex Applications.
The RemoteObject class load classes with the web application classloader
In Flex 1.0, the RemoteObject class uses its own classloader to create objects. Flex 1.5 does not use its own classloader. Because of this, you should remove workarounds used in 1.0 to deal with SAX and other common classes. The workarounds included putting RemoteObject objects in WEB-INF/flex/jars or adding /WEB-INF/classes to the flex.class.path parameter in the web.xml file. Now the normal web application locations of WEB-INF/classes and WEB-INF/lib should work without additional modification.
The suggested way to register client-side classes to server-side Java classes has changed
Flex 1.5 uses the Object.registerClass() method as the preferred way to register client-side ActionScript classes to server-side Java classes. In Flex 1.0, _remoteClass was the recommended way to register them.
For example, a Flex 1.0 ActionScript class might look like the following:
class com.vendor.package.Customer { public function Customer() { _remoteClass = "com.vendor.package.Cust"; } public var _remoteClass:String; ... }
while the corresponding Flex 1.5 ActionScript class would look like the following:
class ocm.vendor.package.Customer { public static var regClass = Object.registerClass("com.vendor.package.Cust",com.vendor.package.Customer); function Customer() ... }
The fully qualified class names of the ActionScript and Java classes do not have to match exactly. In this case, the Java class is named Cust while the ActionScript class is named Customer. However, it is often easier to track your classes and avoid naming errors if you do use the same names for both classes.
For more information, see "Objects that are not handled explicitly" in the Data Services chapter of Developing Flex Applications.
The means of handling session data has changed
Flex 1.0 used the session servlet to handle session data. Flex 1.5 uses the flashgateway.Gateway.getHttpRequest()
, flashgateway.Gateway.getHttpResponse()
, and flashgateway.Gateway.getServletConfig()
methods. To use these methods, you must have the WEB-INF/lib/flashgateway.jar file in your classpath.
For more information, see "Working with session data" in the Data Services chapter of Developing Flex Applications.
RemoteObject objects support by-reference serialization
RemoteObject objects now supports by-reference serialization. You now save space by serializing commonly occuring complex objects such as Arrays, Objects, and Typed Objects. This new functionality also allows you to support groups of objects with circular references, which was not supported in Flex 1.0. Flex 1.5 automatically uses by-reference serialization when appropriate.
The mechanism for using flashvars variables in the JSP Tag Library has changed
When using the Flex JSP Tag Library with Flex 1.5, use the <param>
tag to pass Flash Player parameters only (such as bgcolor
, wmode
, and align
). You should no longer define a flashVars
variable using the <param>
tag.
To send user-defined variables as flashVars
variables, you now use the <flashVar>
tag. The <flashVar>
tag is a child tag of the <mxml>
and <flash>
tags. For example:
<%@ taglib uri="FlexTagLib" prefix="mm" %> <html> <% String fName = request.getParameter("fName"); String lName = request.getParameter("lName"); %> <body> <mm:mxml source="myApp.mxml"> <mm:flashVar name="fName" value="<%=lName%>" /> <mm:flashVar name="lName" value="<%=fName%>" /> </mm:mxml> </body> </html>
For more information, see "Using flashVars" in the Deploying Applications chapter of Developing Flex Applications.
The rules for validating empty data strings have changed
In Flex 1.5, all data validators have a required
property, which defaults to true
. As a result, when you validate blank input, Flex triggers the requiredError
state. To use Flex 1.0 behavior, set required="false"
in the validator tag. For example:
<mx:CreditCardValidator required="false" field="creditcard" />
For more information, see the Validating Data in Flex chapter of Developing Flex Applications.
A NumberValidator validator error code has changed
The invalidCharError
property replaces the notANumberError
property in the NumberValidator validator. The notANumberError
property now throws a compiler error. In your applications, change the following code from this:
<mx:NumberValidator field="model.myAge" notANumberError="New Not A Number Error"/>
<mx:NumberValidator field="model.myAge" invalidCharError="New Invalid Char Error"/>
For more information, see "Number Validator" in the Validating Data in Flex chapter of Developing Flex Applications.
Style changes
The following style changes were made in Flex 1.5:
- The way to access styles has changed
- The Panel container default border style has changed
- Clipping behavior with the cornerRadius property specified has changed
The way to access styles has changed
You can no longer access any style properties directly. You must instead use the getStyle()
and setStyle()
methods to get or set the values of style properties. For example:
event.target.getStyle("backgroundColor")
For more information, see "Using the setStyle() and getStyle() methods" in the Using Styles and Fonts chapter of Developing Flex Applications.
The Panel container default border style has changed
The default border thickness of the Panel container is now 0. It was 1 pixel in Flex 1.0. If you set borderStyle="solid"
, you must also set borderThickness="1"
.
In Flex 1.0, the following example produces a solid border of 1 pixel:
<mx:Application xmlns:mx="http://www.macromedia.com/2003/mxml" xmlns="*" backgroundColor="0xFFFFFF"> <mx:Panel title="My Panel" borderStyle="solid"> <mx:TextArea width="100" height="200" text="There should be a 1 pixel border around me" /> </mx:Panel> </mx:Application>
In Flex 1.5, this example produces a solid border of 1 pixel:
<mx:Application xmlns:mx="http://www.macromedia.com/2003/mxml" xmlns="*" backgroundColor="0xFFFFFF"> <mx:Panel title="My Panel" borderStyle="solid" borderThickness="1"> <mx:TextArea width="100" height="200" text="There should be a 1 pixel border around me" /> </mx:Panel> </mx:Application>
For more information on Panel containers, see "Panel layout container" in the Using Layout Containers chapter of Developing Flex Applications.
Clipping behavior with the cornerRadius property specified has changed
In Flex 1.0, if you tried to set a corner radius and it wasn't supported by the current style, no clipping occurred. In Flex 1.5, your component is clipped regardless of whether the cornerRadius
property is actually supported. You should not set cornerRadius
unless it is supported by your current style.
The following example illustrates the effect of setting the cornerRadius
property when it isn't supported:
<mx:Application xmlns:mx="http://www.macromedia.com/2003/mxml" height="500" width="500" initialize="doInit()" verticalGap="100"> <mx:Script><![CDATA[ function doInit() { b1.fillRect(20, 20, 120, 120, 0xFFCCFF, 50); b2.fillRect(20, 20, 120, 120, 0xFFCCFF, 50); } ]]></mx:Script> <mx:Box id="b1" width="100" height="100" borderStyle="inset" /> <mx:Box id="b2" width="100" height="100" borderStyle="inset" cornerRadius="3"/> </mx:Application>
Custom component changes
The following custom component changes were made in Flex 1.5:
- The commitProperties() method is only called if the invalidateProperties() method is called
- The means of handling properties of child components in custom components has changed
- The eventnameHandler() method in ActionScript components is only invoked if you register for it
- Scroll bar behavior when createChildren() is not called has changed
The commitProperties() method is only called if the invalidateProperties() method is called
To improve performance, Flex 1.5 no longer automatically calls the commitProperties()
method after the createChildren()
method during the application or component initialization stage. If this functionality is essential for your application, call the invalidateProperties()
method at the end of your createChildren()
method. This will force a call to the commitProperties()
method.
For example, the following createChildren()
method initializes a TextInput control and a SimpleButton control, then calls the invalidateProperties()
method to invoke the commitProperties()
method:
// Declare two children member variables. var text_mc:TextInput; var mode_mc:SimpleButton; // Declare default skin names for the button states. // This is optional if you do not want to allow skinning. var modeUpSkinName:String = "ModalUpSkin"; var modeOverSkinName:String = "ModalOverSkin"; var modeDownSkinName:String = "ModalDownSkin"; // Note that we test for the existence of the children before creating them. // This is optional, but we do this so a subclass can create a different // child instead. function createChildren():Void { if (text_mc == undefined) createClassObject(TextInput, "text_mc", 0, { preferredWidth: 80, editable:false }); text_mc.addEventListener("change", this); text_mc.addEventListener("focusOut", this); if (mode_mc == undefined) createClassObject(SimpleButton, "mode_mc", 1, { falseUpSkin: modeUpSkinName, falseOverSkin: modeOverSkinName, falseDownSkin: modeDownSkinName }); mode_mc.addEventListener("click", this); invalidateProperties(); }
For more information, see "About the component instantiation life cycle" in Creating Advanced Components in Flash MX 2004 chapter of Developing Flex Components and Themes in Flash Authoring.
The means of handling properties of child components in custom components has changed
If you write a property setter for a custom Flex component, the setter function may be called before the component's children have been created. Therefore, the code in the setter function should not assume that the component's children already exist.
In Flex 1.0, you used clip parameters to handle this situation. In Flex 1.5, if the setter function needs to read or write the properties of the component's children, the setter function should not process the new property value immediately. Instead, it should store a record of the new property value and delay processing until the commitProperties()
method is called.
In the following example, the setter function for propertyA does not call the updateChildSizes()
function immediately. Instead, it sets a flag and calls the function later, in the commitProperties()
method:
var _propertyA:String; var _updatePendingPropertyA:Boolean = false; function get propertyA():String { return _propertyA; } function set propertyA(newValue:String): Void { // Store the new value for property A. _propertyA = newValue; // Instead of processing the new property value immediately, // set a flag that will remind us to process it later. _updatePendingPropertyA = true; // Tell Flex to call the commitProperties function later. invalidateProperties(); } // If invalidateProperties has been called, this function // will be invoked after the component's children have been initialized. function commitProperties() { if (_updatePendingPropertyA) { // Adjust properties on the component's children. For example, we might // change the position or sizes of the component's children, based on // the new value of propertyA. updateChildSizes(); _updatePendingPropertyA = false; } }
An alternative approach is to write a general method to check whether the children exist and then set your property values and call the invalidateProperties()
method once they do. This approach can be easier to write if you have many properties to set, but, because it has to constantly poll for the existence of the child components, it affects performance.
The following example illustrates a series of property setters in Flex 1.0; they will not work in Flex 1.5:
<VBox verticalGap="0" width="200" xmlns="http://www.macromedia.com/2003/mxml"> <TextInput id="textbox" widthFlex="1" borderStyle="none" fontWeight="normal" focusIn="textbox.setStyle('backgroundColor','#EEEEEE')" focusOut="textbox.setStyle('backgroundColor','#FFFFFF')"/> <HRule widthFlex="1" color="Black" tabEnabled="false"/> <Label fontSize="8" id="labelbox" fontWeight="bold" /> <Script> <![CDATA[ function get mytext():String { return textbox.text; } function set mytext(value:String):Void { textbox.text = value } function set mylabel(value:String):Void { labelbox.text=value; } ]]> </Script> </VBox>
The following example uses the polling approach to rewrite the previous example for Flex 1.5:
<VBox verticalGap="0" width="200" xmlns="http://www.macromedia.com/2003/mxml"> <TextInput id="textbox" width="100%" borderStyle="none" fontWeight="normal" focusIn="textbox.setStyle('backgroundColor','#EEEEEE')" focusOut="textbox.setStyle('backgroundColor','#FFFFFF')" /> <HRule width="100%" color="Black" tabEnabled="false"/> <Label fontSize="8" id="labelbox" fontWeight="bold" /> <Script> <![CDATA[ var pendingProps:Array = new Array(); var hasPending:Boolean; function get text():String { return textbox.text; } function set text(value:String):Void { addPendingProps(value,"textbox","text"); } function set label(value:String):Void { addPendingProps(value,"labelbox","text"); } function commitProperties():Void { var prop; var obj; while (pendingProps.length > 0) { prop = pendingProps.pop(); obj = eval(prop.name); if (prop.prop != undefined) obj[prop.prop] = prop.value; else obj = prop.value; } } function addPendingProps(value:Object,obj:String, prop:String) { var propObj = new Object(); propObj.name = this+ "." + obj; propObj.value = value; propObj.prop = prop; pendingProps.push(propObj); invalidateProperties(); } ]]> </Script> </VBox>
For more information, see "Working with component properties" in the Creating Basic Components in Flash MX 2004 chapter of Developing Flex Components and Themes in Flash Authoring.
The eventnameHandler() method in ActionScript components is only invoked if you register for it
To improve performance, Flex 1.5 no longer automatically calls the eventnameHandler()
method when an event is triggered. When an event called eventname is triggered in Flex 1.0, the system checks to see if the eventnameHandler()
method exists. If it does, it is automatically called. Flex 1.5 does not perform this check. If you want the eventnameHandler()
method to run when eventname is triggered, you must register it by calling the addEventHandler()
method.
Macromedia recommends using the EventListener and handleEvent syntax to add an event handler to a component in ActionScript. For example, Macromedia recommends the following code to add a click event for a button:
class Foo { var child:Button function createChildren() { createClassObject(Button, "child", 0); child.addEventListener("click", this); } function handleEvent(event:Object) { if (event.type == "click") { // The 'this' pointer points to the instance of Foo. } } }
In Flex 1.0, the following shortcut saved a line of code, a little bit of memory, and some processing time:
class Foo { var child:Button function clickHandler () { // The 'this' pointer points to the instance of Button. } function createChildren() { createClassObject(Button, "child", 0); child.clickHandler = clickHandler; } }
However, in large applications, the overhead of checking for the shortcut overwhelmed the savings of this mechanism. Flex 1.5 no longer automatically calls the clickHandler mechanism. Macromedia recommends rewriting your code to use the handleEvent()
method. However, if the effort to rewrite the code is too significant, you can call the clickHandler()
method manually by using the createChildren()
method supplied below instead of the one immediately above:
function createChildren() { createClassObject(Button, "child", 0); child.clickHandler = clickHandler; child.addEventHandler("click"); }
For more information, see "Handling events" in the Creating Advanced Components in Flash MX 2004 chapter of Developing Flex Components and Themes in Flash Authoring.
Scroll bar behavior when createChildren() is not called has changed
In Flex 1.0, scroll bars did not appear if you failed to call the createChildren()
method in your custom containers. In Flex 1.5, scroll bars appear if they are appropriate, regardless of whether the createChildren()
method is called. All custom containers should call the createChildren()
method during their initialization stage.
For more information, see "Implementing the createChildren() method" in the Creating Advanced Components in Flash MX 2004 chapter of Developing Flex Components and Themes in Flash Authoring.
Miscellaneous changes
The following miscellaneous changes were made in Flex 1.5:
- The Slider control is now a standard component
- Changing a URL parameter no longer automatically causes Flex to recompile your application
- Using the same labelFunction value for more than one DataGridColumn in a DataGrid control is now supported
- Possible creationIndex variable conflict may occur
- The ControlBar container no longer supports scroll bars
- The selectedNode property data type has changed
- The web.xml file has changed
The Slider control is now a standard component
The Slider control is now part of the standard Flex components. It is no longer in the /extras folder. You should remove the slider.swc file from the samples directory and any other directory to which you copied it. Use the new Horizontal Slider (<mx:HSlider/>
) and Vertical Slider (<mx:VSlider/>
) controls in your applications.
For more information, see "HSlider and VSlider controls" in the Using Controls chapter of Developing Flex Applications.
Changing a URL parameter no longer automatically causes Flex to recompile your application
In Flex 1.0, every time you changed a parameter in the URL, Flex recompiled your application. In Flex 1.5, your application is only recompiled if the parameter change causes the SWF file to be out-of-date. Otherwise, the HTML is regenerated without recompiling the Flash file. This change should greatly improve the performance of applications that use URL parameters.
For more information, see "About the HTML wrapper" in the Deploying Applications chapter of Developing Flex Applications.
Using the same labelFunction value for more than one DataGridColumn in a DataGrid control is now supported
You can now use the same labelFunction
value for more than one DataGridColumn in a DataGrid control. The DataGridColumn labelFunction
property now takes a second argument that is set to a DataGridColumn name. In the following example, all of the DataGridColumns use myLabelFunction
:
<?xml version="1.0"?> <mx:Application xmlns:mx="http://www.macromedia.com/2003/mxml" backgroundColor="#FFFFFF"> <mx:Script> function myLabelFunction(itmObj, colName) { if(itmObj != null) { return "$" + itmObj[colName]; } } </mx:Script> <mx:DataGrid id="myGrid"> <mx:columns> <mx:Array> <mx:DataGridColumn columnName="ItemName" /> <mx:DataGridColumn columnName="WholeSalePrice" labelFunction="myLabelFunction"/> <mx:DataGridColumn columnName="RetailPrice" labelFunction="myLabelFunction"/> <mx:DataGridColumn columnName="Tax" labelFunction="myLabelFunction"/> </mx:Array> </mx:columns> <mx:dataProvider> <mx:Array> <mx:Object ItemName="Item1" WholeSalePrice="8.99" RetailPrice="11.99" Tax="1.25" /> <mx:Object ItemName="Item2" WholeSalePrice="12.99" RetailPrice="15.99" Tax="1.50" /> </mx:Array> </mx:dataProvider> </mx:DataGrid> </mx:Application>
For more information, see "Using a label function" in the Using Data Provider Controls chapter of Developing Flex Applications.
Possible creationIndex variable conflict may occur
Flex 1.5 uses a creationIndex
variable to support a formal technique for progressive layout. If your code defines a variable called creationIndex
, as described in previous sample applications that use Progressive Layout, you should give the creationIndex
property a different variable name.
If you don't rename this variable, the code generates the following compiler warning:
The member, creationIndex, hides a member in ancestor class, 'mx.containers.Container'.
For more information, see "Setting queue order" in the Improving Startup Performance chapter of Developing Flex Applications.
The ControlBar container no longer supports scroll bars
If their content was too large to fit, Flex 1.0 ControlBar containers sprouted scroll bars. In Flex 1.5, any content that does not fit into the ControlBar container is clipped. Scroll bars are not supported.
For more information, see "ControlBar layout container" in the Using Layout Containers chapter of Developing Flex Applications.
The selectedNode property data type has changed
In Flex 1.0, the selectedNode
property of the Tree class always returned data as an XMLNode when you got its value. In Flex 1.5, it returns data as a TreeDataProvider. The property accepts both XMLNodes and TreeDataProviders as input in both Flex 1.0 and Flex 1.5.
For more information, see "Tree control syntax" in the Using Data Provider Controls chapter of Developing Flex Applications.
The web.xml file has change
The following entries were completely removed from the web.xml file in Flex 1.5:
-
<context-param> <param-name>flex.configuration.file</param-name> <param-value>/WEB-INF/flex/flex-config.xml</param-value> <description>configuration file</description> </context-param>
-
<context-param> <param-name>flex.listener.class</param-name> <param-value>flex.cache.DependencyCheckerService</param-value> </context-param>
-
<listener> <listener-class>flex.bootstrap.BootstrapListener</listener-class> </listener>
-
<servlet> <servlet-name>FlexAxisServlet</servlet-name> <display-name>Apache-Axis Servlet</display-name> <servlet-class>flex.bootstrap.BootstrapServlet</servlet-class> <init-param> <param-name>servlet.class</param-name> <param-value>flex.remote.CustomAxisServlet</param-value> </init-param> </servlet>
-
<init-param> <param-name>servlet.class</param-name> <param-value>flashgateway.controller.GatewayServlet</param-value> </init-param>
-
<servlet-mapping> <servlet-name>FlexAxisServlet</servlet-name> <url-pattern>/flex-ws/*</url-pattern> </servlet-mapping>
-
<error-page> <error-code>404</error-code> <location>/flex-error</location> </error-page>
The following entries were modified in the web.xml file in Flex 1.5:
-
<param-value>./WEB-INF/flex/jars</param-value>
is now
<param-value>/WEB-INF/flex/jars</param-value>
-
<param-value>flex.detection.DetectionFilter</param-value>
is now
<param-value>flex.server.j2ee.DetectionFilter</param-value>
-
<param-value>flex.cache.CacheFilter</param-value>
is now
<param-value>flex.server.j2ee.cache.CacheFilter</param-value>
-
<param-value>flex.flashproxy.ProxyServlet</param-value>
is now
<param-value>flex.server.j2ee.proxy.ProxyServlet</param-value>
-
<param-value>flex.mxml2.ErrorPageServlet</param-value>
is now
<param-value>flex.compiler.ErrorPageServlet</param-value>
-
<param-value>flex.filemanager.FileManagerServlet</param-value>
is now
<param-value>flex.server.j2ee.filemanager.FileManagerServlet</param-value>
-
<param-value>flex.swfmanager.SwfServlet</param-value>
is now
<param-value>flex.server.j2ee.SwfServlet</param-value>
-
<param-value>flex.mxml2.MxmlServlet</param-value>
is now
<param-value>flex.compiler.MxmlServlet</param-value>
-
<servlet-class>flex.bootstrap.BootstrapServlet</servlet-class>
is now
<servlet-class>flashgateway.controller.GatewayServlet</servlet-class>
-
<param-value>flex.util.ForbiddenServlet</param-value>
is now
<param-value>flex.server.j2ee.ForbiddenServlet</param-value>
-
<param-value>flex.remote.Session</param-value>
is now
<param-value>flex.server.j2ee.remote.Session</param-value>
-
<welcome-file>index.html</welcome-file>
is now
<welcome-file>index.htm</welcome-file>
The following entries were added to the web.xml file in Flex 1.5:
-
<servlet-mapping> <servlet-name>FlexForbiddenServlet</servlet-name> <url-pattern>*.sws</url-patternv </servlet-mapping>
For more complete information on the changes to the web.xml file and what they mean, see "Adding Flex to an existing web application" in the Deploying Applications chapter of Developing Flex Applications.
Features Removed in Flex 1.5
In some cases, functionality has been completely removed in Flex 1.5, while in other cases functionality has been deprecated. This section covers the following topics:
- Features completely removed in Flex 1.5
- How Flex handles deprecation
- Features deprecated in Flex 1.5
Features completely removed in Flex 1.5
The following features are no longer part of Flex:
- The configuration file jrun-web.xml has been removed to make Flex more independent of the application server used.
- The
cache-mxml
property in the <cache> section of the flex-config.xml file was removed. This property existed but was ignored in earlier versions of Flex.
How Flex handles deprecation
In some cases, functionality has been deprecated in Flex 1.5. Deprecated features and properties do the following:
- Generate compilation warnings
- Continue to work in Flex 1.5
- Will be removed from the product in a future major release
You can suppress deprecation warnings by setting show-deprecated-warnings
to false
in the flex-config.xml file.
Features deprecated in Flex 1.5
The following features have been deprecated in Flex 1.5:
- The
widthFlex
property. It has been replaced by percentage support in thewidth
property. - The
heightFlex
property. It has been replaced by percentage support in theheight
property. - The
setRelativeChildWidths()
method. It has been superceded by percentage support in thewidth
property. - The
setRelativeChildHeights()
method. It has been superceded by percentage support in theheight
property. - The
html
property. Use thehtmlText
property instead. - The
encoding
property of the RemoteObject class. It is no longer needed because AMF is the only supported encoding.
Upgrading from the Flex 1.5 Beta version
The Flex 1.5 installer does not support installing over a Beta version of Flex 1.5. You must uninstall any previous installation of the Flex 1.5 Beta before you install the released version. If you have a Flex 1.5 Beta installed, and you attempt to install the released version into the same location, the installer prompts you to enter a different location.