In the first article in this series (MXDJ, Vol. 2, issue 10) I made the case for the rich Internet application (RIA) and discussed the advantages of the Flash client. Last month we examined the construction of an XML driven RIA built using Flash S data and UI components. This month we look at how ColdFusion provides a simple but powerful way to make data available as both a Web service and a Flash Remoting data source.

  Data can be made available via Web services using several technologies, including ColdFusion. Data exposed through a Web service can be used by both Flash and non-Flash clients. If your Web service represents data using standard data types such as arrays and objects (or structures in ColdFusion), the data can be used in other technologies such as ASP.NET, PHP, or Java. Web services obtain this flexibility by using a standardized method of describing and exchanging data and commands. The exchange is formatted using an XML schema called SOAP, the Simple Object Access Protocol. This flexibility is gained at the expense of some efficiency. An exchange of data and commands between a specific server technology and a specific client can be optimized for that specific client/server technology. This is the benefit of Flash Remoting.

Flash Remoting data sources, such as Web services, can be produced by several technologies, including ASP.Net, PHP, Java, and our favorite server application technology, ColdFusion. Flash Remoting exchanges commands and data with the Flash client using a binary format called AMF, the Action Message Format. This binary exchange is more efficient than the text-based XML structure of SOAP. Flash Remoting data sources provide the most efficient means of communication between the Flash client and the server.

There is an important issue regarding data types that developers should make note of. The results of a ColdFusion query in their native form may not be usable in other frameworks. Also, the results from queries in other technologies such as ASP.NET may not be usable in Flash.

We conceptualize and work with data from a query as an array of objects in Flash. Each record is an object and the record's fields become the object's properties. The records/objects are then stored in an array.

However, in its native format data returned by a query may not be usable across different frameworks. The exact structure of the data returned by a query will be specific to the server technology that created it. It will not be a simple array of objects. This may prevent the data from being used in other technologies.

To achieve interoperability across server technologies, developers should parse database results into a generic array of objects (or in ColdFusion, an array of structures.) This data structure will then be able to be used by clients built in other frameworks.

The good news is, when you work with a ColdFusion data source and a Flash client, the results of a database query may easily be passed directly from the server to Flash. While clients written in other technologies may not be able to use this data source, it will work fine with the Flash client. This represents both the easiest and most efficient way of passing database information from ColdFusion to Flash via both Web services and remoting.

The focus of this article is on a ColdFusion data source for a Flash client. The ColdFusion data source that we will examine here will be designed to pass the results of a ColdFusion query directly to a Flash client. Readers who wish to use a ColdFusion data source for other clients should be prepared to parse the CF query into a generic array of objects.

ColdFusion Components (CFCs) represent ColdFusion's entry into object-oriented programming. CFCs provide the power of object-oriented development while maintaining the classic friendliness of ColdFusion. CFCs provide a familiar tag-based development model that leverages the power of the JRun J2EE engine that lies at the heart of the ColdFusion MX server.

CFCs are a collection of one or more ColdFusion functions. The CFC itself can have values associated with it. Those of you reading this who are familiar with object-oriented programming (OOP) may recognize what we have here - a Class.

A Class is a collection of methods (functions) and properties (values). A CFC is a collection of functions and values. CFCs are Class files they are ColdFusion's object-oriented building blocks. CFCs become Java classes on the server offering the power of Java and the ease of ColdFusion.

Dreamweaver is the current development tool for ColdFusion applications, and does a real fine job. (I hear the groans and sneers from you ColdFusion Studio users. <grin />) Anyway, Dreamweaver is the development tool we'll be using here. It will provide us with a starter file we can modify to create our data source.

From Dreamweaver's new file dialogue choose ColdFusion Component from the Dynamic Pages Category (see Figure 1). Dreamweaver creates a new document with a generic skeleton of the key elements of a CFC.

For this example, the file will be saved as flashDataSource.cfc into a directory called myCFC in the web root of the server. Note the .cfc extension instead of the traditional .cfm. Now let's examine the flashDataSource.cfc.

The outer <cfcomponent></cfcomponent> declares the ColdFusion component. It is comparable to the class declaration in Java and ActionScript 2.0. A cfcomponent tag contains one or more user defined functions (UDFs), or what most developers would just call functions. Dreamweaver has provided an example of a UDF in our CFC.

While they work the same as functions developers may be familiar with from other languages, ColdFusion's UDFs are constructed very differently. UDFs follow ColdFusion's tag-based syntax. This can easily be seen in the opening cffunction tag in line 2 of Figure 2.

The name of the function is declared in the name attribute of the cffunction tag. The data type of the return from the function is also an attribute; returntype. A bit strange compared to other languages, but not difficult to understand.

The most interesting attribute of the cffunction tag is the access attribute. This is the magic key to creating a Web service and Flash Remoting datasource from a CFC.

The access attribute accepts four values: private, package, public, and remote. These values determine from where and how the function may be accessed.

An access value of private is the most restrictive. It allows only other functions in the same CFC to use the function.

An access value of package allows any other CFC in the same directory to use the function. Here the Java underneath the CFC shows itself. A directory of Classes is called a package in Java.

A public access value means that any CFC anywhere on our server can use it.

An access value of remote means that clients outside of our server can use our function as either a Web service or a Flash Remoting data source. The ColdFusion server takes care of the translation of all requests and results to and from the appropriate format: SOAP or AMF. The ColdFusion server can even produce the metadata that clients need to help consume our Web service, the WSDL file (Web Service Description Language). More on WSDLs later.

After the opening cffunction tag we encounter a cfargument tag in line 3. While a traditional function would pass its arguments as a list in the function declaration's parenthesis, ColdFusion uses separate cfargument tags to pass values to the cffunction.

Notice the attributes for the argument name as well as for data typing and making the argument required. Unlike typical ColdFusion, which is loosely typed, CFCs provide strong data typing similar to ActionScript 2.0 and Java.

Line 4 shows us how to set a variable in the function and line 5 shows us how to return it from the function.

There is more code here than we need for our data source. We won't need any variables in our function and we will not need any arguments, so we can delete lines 3 and 4. Now we will start modifying the cffunction.

The function should have a descriptive name. Since our data source will provide the client with product data we will name our cffunction getAllProducts.

The most important attribute for our data source is the access attribute. Setting the access attribute to remote makes this function available as both a Web service and Flash Remoting data source.

The returntype of the function is set to query. We are going to pass the result of our database query straight to Flash. We still need to modify the return statement but that can wait until we add the query to our function.

Our data source is called productsDSN. The result of the cfquery will be called qProducts, and the query will pull all information from a table called Products. The cfquery will look like Figure 3.

The cfreturn line can now be modified to return our query: qProducts.

The final CFC will have only eight lines of code (see Figure 4).

We now have the data source we will use in future articles. For those of you who can't wait and want to start using our data source, be aware of one important issue. The ColdFusion server installs with Flash access to Web services and remoting turned off. The FlashGateway must be enabled for our CFC to work as a Flash data source. How the FlashGateway is turned on varies with the version of ColdFusion you are running. See Macromedia's ColdFusion TechNote #18608 for details.

That's it for this month. Next month we use our data source to feed data to Flash as a Web service and from there we move on to remoting. See you then!