| Flex 2 Developer's Guide >
Building User Interfaces for Flex Applications > Using Data Providers and Collections > About data providers and collections |
|||
Many controls and containers require data for display, for user interaction, or to structure a control such as a menu. To provide this data, you must understand the concepts of data providers and collections and how collections work.
Several Flex framework components, including all List based controls, represent data from a data provider, an object that contains data required by the control. For example, a Tree control's data provider determines the structure of the tree and any associated data assigned to each tree node, and a ComboBox control's data provider determines the items in the control's drop-down list. Many standard controls, including the ColorPicker and MenuBar controls also get data from a data provider. Controls that display application data are sometimes referred to as data provider controls.
The following components use data providers:
The simplest data provider can be an array of strings or objects; for example, you can use the following code to define a static ComboBox control:
<?xml version="1.0"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
<mx:Script>
<![CDATA[
[Bindable]
public var myArray:Array = ["AL", "AK", "AR"];
]]>
</mx:Script>
<mx:ComboBox id="myCB0" dataProvider="{myArray}"/>
</mx:Application>
However, using a raw data object, such as an Array or Object, as a data provider has limitations:
dataProvider property. Flex provides a collection mechanism to ensure data synchronization and provide both simpler and more sophisticated data access and manipulation tools. Collections can also provide a consistent interface for accessing and managing data of different types. For more information on collections, see About collections.
For detailed descriptions of the individual controls, see the pages for the controls in Adobe Flex 2 Language Reference. For information on programming with many of the data provider-based controls, see Using Data-Driven Controls.
The Flex framework supports two basic types of data provider:
Linear or list-based data providers are flat data consisting of some number of objects, each of which has the same structure; they are often one-dimensional Arrays, or objects derived from such Arrays, such as ActionScript object graphs. (You can also use an XMLListCollection object as a linear data provider.)
You can use list-based data providers with all data provider controls, and typically use them for all such controls except Tree and most menu-based control instances. If the data provider contents can change dynamically, you typically use the ArrayCollection class and either the IList or ICollectionView interface methods and properties to represent and manipulate these data providers.
Hierarchical data providers consist of cascading levels of often asymmetrical data. Often, the source of the data is an XML object, but the source can be a generic Object or concrete class. You typically use a hierarchical data providers with Flex controls that are designed to display hierarchical data:
You can also extract data from hierarchical data provider to use in controls such as List or DataGrid that take linear data.
A hierarchical data provider defines a data structure that matches the layout of a tree or cascading menu. For example, a tree often has a root node, with one or more branch or leaf child nodes. Each branch node can hold additional child branch or leaf nodes, but a leaf node is an endpoint of the tree.
The Flex hierarchical data controls use data descriptor interfaces to access and manipulate hierarchical data providers, and the Flex framework provides one class, the DefaultDataDescriptor class that implements the required interfaces. If your data provider does not conform to structure required by the default data descriptor, you can create your own data descriptor class that implements the required interfaces.
You can use an ArrayCollection class, XMLListCollection class, ICollectionView interface or IList interface to access and manipulate dynamic hierarchical data.
For more information on using hierarchical data providers, see Using hierarchical data providers.
Flex data-driven controls, including all controls that are subclasses of List class, use a unique identifier (uid) to track data provider items. Flex can automatically create and manage uids. However, there are circumstances when you must supply your own uid property by implementing the IUID interface, or when supplying your own uid property improves processing efficiency.
|
NOTE |
|
When Flex creates a UID for an object, such as an item in an ArrayCollection, it adds the UID as an |
If Flex must consider two or more different objects to be identical you must implement the IUID interface so that you can assign the same uid to multiple objects. A typical case where you must implement the IUID interface is an application that uses windowed paged collections. As the cursor moves through the collection, a particular item might be pulled down from the server and released from memory repeatedly. Every time the item is pulled into memory a new object is created to represent the item. If you need to compare items for equality, Flex should consider all objects that represent the same item to be the same "thing."
More common than the case where you must implement the IUID interface is the case where you can improve processing efficiency by doing so. As a general rule, you do not implement the IUID interface if the data provider elements are members of dynamic classes. Flex can automatically create a uid property for these classes. There is still some inefficiency however, so you might consider implementing the IUID interface if processing efficiency is particularly important.
In all other cases, Flex uses the Dictionary mechanism to manage the uid, which might not be as efficient as supplying your own UID.
Because the Object and Array classes are dynamic, you normally do not do anything special for data providers whose items belong to these classes. However, you should consider implementing the IUID if your data provider members belong to custom classes that you define.
The IUID interface contains a single property, uid, which is a unique identifier for the class member, and no methods. Flex provides a UIDUtil class that uses a pseudo-random number generator to create an identifier that conforms to the standard GUID format. Although this identifier is not guaranteed to be universally unique, it should be unique among all members of your class. To implement a class that uses the UIDUtil class, such as a Person class that has fields for a first name, last name, and id, you can use the following pattern:
Revised 2/26/2007: changed '_uid = createUID();' to '_uid = UIDUtil.createUID();' (added UIDUtil.).
package {
import mx.core.IUID;
import mx.utils.UIDUtil;
[Bindable]
public class Person implements IUID {
public var id:String;
public var firstName:String;
public var lastName:String;
private var _uid:String;
public function Person() {
_uid = UIDUtil.createUID();
}
public function get uid():String {
return _uid;
}
public function set uid(value:String):void {
// Do nothing, the constructor created the uid.
}
}
}
You do not need to use the UIDUtil class in a case where the objects contain a uniquely-identifying field such as an employee ID. In this case, you can use the person's ID as the uid property, because the uid property values have uniquely identify the object only in the data provider. The following example implements this approach.
package
{
import mx.core.IUID;
[Bindable]
public class Person implements IUID {
public var employee_id:String;
public var firstName:String;
public var lastName:String;
public function get uid(): String {
return employee_id;
}
public function set uid(value: String): void {
employee_id=value;
}
}
}
|
NOTE |
|
Object cloning does not manage or have a relationship with UIDs, so if you clone something that has an internal UID you must also change that internal UID. UIDs are stored on mx_internal_uid only for dynamic Objects. Instances of data classes that implement IUID will store their UIDs in a .uid property so that is the property that must be changed after cloning. However, dataproviders do not need to implement IUID. If they are instances of data classes that do not implement IUID and are not dynamic objects, the clone technique should work correctly, but most dataprovider items should implement IUID, especially if cloning those objects is not required. |
Flex 2.01
RSS feed | Send me an e-mail when comments are added to this page | Comment Report
Current page: http://livedocs.adobe.com/flex/201/html/about_dataproviders_057_02.html
Comments
JamesDad said on Feb 25, 2007 at 3:00 PM :