Supercharge Your Flex App with ColdFusion Power

A Flex application to cater for such a service call would look like:

<?xml version="1.0" encoding="utf-8"?>  
<mx:Application  
 xmlns:mx="http://www.adobe.com/2006/mxml"  
 layout="horizontal"  
 creationComplete="cfmFile.send()">  
 
   <mx:Script>  
       <![CDATA[  
           import mx.controls.Alert;  
           import mx.rpc.events.ResultEvent;  
           import mx.rpc.events.FaultEvent;  
           import mx.collections.ArrayCollection;  
 
           [Bindable]  
           private var budgetData:ArrayCollection = new ArrayCollection();  
 
           private function cfmFileRH(e:ResultEvent):void  
           {  
               budgetData = e.result.data.result as ArrayCollection;  
           }  
 
           private function cfmFileFH(e:FaultEvent):void  
           {  
               mx.controls.Alert.show(e.fault.faultString,"Error when loading XML");  
           }  
 
 
       ]]>  
   </mx:Script>  
 
   <mx:HTTPService  
   id="cfmFile"  
   url="http://example.com/budgetXML.cfm"  
   result="cfmFileRH(event)"  
   fault="cfmFileFH(event)"  
   />  
 
   <mx:DataGrid dataProvider="{budgetData}" >  
   </mx:DataGrid>  
 
</mx:Application>

Here’s what’s happening: we’re using an mx:HTTPService to grab some data, and storing the result from the service in a variable named budgetData. The creationComplete event handler on the tag sends the HTTPService request when the application is created. Finally, a mx:DataGrid object displays the data as a table.

Looking closely at the mx:HTTPService we can see that it includes two attributes: result and fault. In Flex, any data service request is dealt with asynchronously, meaning that the Flex application will immediately broadcast a result event instead of waiting for a response. All service tags offer the attributes result and fault to deal with either of these outcomes. In those attributes you’d just specify the name of the method you’d like to be called whenever a result (or a fault) comes back from the service call.

Practically speaking, an instance of mx:HTTPService is limited to GET and POST requests, although in principle other requests can be issued—but these are unavailable unless the HTTP requests are being routed via a proxy server, such as Adobe’s BlazeDS or LiveCycle Data Services. The reason for that limitation is the security model of the Flash Player, which only supports direct GET or POST calls via HTTP. That’s where another concept enters the game: a cross-domain policy file.

Normally, a Flash-based application using an mx:HTTPService or a SOAP-based web service may only retrieve data from a service or file stored on the same server as the .swf file. To determine whether the data is being pulled from the same domain, Flash Player compares the domain names used for the Flash file and the remote data source. This means that an application loaded from http://localhost/test.swf is unable to access HTTP data from http://127.0.0.1/data/xmlfile.xml—even though they are the same server. One solution is to use a cross-domain policy file, named crossdomain.xml, placed in the web root of the server that’s meant to provide the data. You can learn more about how to use a cross-domain policy file in Adobe’s documentation.

Next, let’s find out about sending request parameters within Flex.