Getting Started: Linked Combo Boxes with Flex
Another example from the customer request list - linked combo boxes. The goal from an information perspective is generally to allow the end-user to drill down into data that is related. Similar in fashion to the needs of a multi-step process, save each step is a single combo box. The first combo box is populated automatically. Based on the selection made, subsequent combo boxes change the values available in their lists.
I’m not 100% this example needs to be posted, but since the customer couldn’t find an existing example that met their needs, I assume there are others out there that are also looking. Source code is available for download and there’s the obligatory Captivate demonstration at the end of the post.
It’s important to recognize that this isn’t too far off of what’s already available in the Flex Samples Explorer under Quick Tour -> Web Services. The differences are that (a) I’m using a JSP to generate XML for an HTTPService versus a WebService and (b) the secondary list isn’t a DataGrid but a ComboBox. If the functionality is the same, but the service and controls are different, then what impact does that have on the application logic?
When dealing with web services you are typically working with object data, object arrays, or primitive data types. In the case of an XML HTTP service, you are dealing with an array of nodes. Flex automatically goes the extra distance to make the nodes resemble an array of objects (which you can turn off and parse yourself if you so please), but it’s not quite the same. Take for example the following line of code used to perform data-binding from each of the two service types.
A) Web Service
<mx:ComboBox dataProvider=”{myService.result}” labelField=”name” />
B) XML HTTP Service
<mx:ComboBox dataProvider=”{myService.result.company.department}” labelField=”name” />
When using a web service, the result itself is the array of objects. All you have to do is point the data provider at that array and you’re done (well, almost). When using XML, the result simply contains the document and from there you need to specify the specific grouping of nodes in which you are interested. In this case “company” represents the parent node of the document itself and “department” represents the item node we want to display.
There’s an extra attribute there you might have noticed; the ComboBox.labelField property specifically. The ComboBox control expects an array of objects as its data provider. Those objects are expected to have a “label” and a “data” property. The label property is what gets displayed while the data property reflects hidden information about the list item (such as a primary key ID or other unique identifier).
But what if your objects don’t have label and data properties? That’s where the ComboBox.labelField property comes into play. The labelField property lets you tell the combo box what property it is that you want to display. The labelField property also exists on the List control, and even takes the form of “columnName” on the DataGridColumn class. The answer to the second difference then, is that there’s really no difference if you’re binding to a List, a ComboBox, or a DataGrid (or any other control).