Page 2 of 4   « previous page   next page »

Coding the Search Query
As you may expect, you must write ColdFusion code to search the database. The sample files contain a ColdFusion component (CFC), components/ListingGateway.cfc, that queries the database but you could use a custom tag as well.

The search in this component has several arguments that correspond to the different search criteria: status, price, pool and other amenities, and so forth. It contains a simple query using the cfquery tag. All the arguments have a default value and the SQL statements will vary each time a user specifies a different combination of arguments. For instance, if the user doesn't enter a status, the CFC ignores that criteria; therefore, the SQL statement will not contain that column in its WHERE clause. To exclude it, we used a simple cfif tag (see Listing 1).

When the query finishes processing, the CFC returns the results to the caller through the <cfreturn listingQuery /> tag.

So far, you should be familiar with the methods used. You created a form to request data from the user and wrapped a query in a CFC to retrieve data from a database. You may be wondering how to connect the form and the CFC. Read onward.

Creating the Flash Remoting Service
Flash Remoting is a Macromedia technology that lets Flash Player make asynchronous calls to Web services and receive responses back from the call. During these calls, it can send and receive sets of data. It consists of a gateway that sits on the server and some components that are included in the SWF file. Fortunately, ColdFusion 7 already contains the Flash Remoting gateway, so you don't have to install any additional software. The SWF files generated by Flash Forms also contain the Flash Remoting components because they are used internally.

Just as Web services do, you must place Flash Remoting services in a Web-accessible directory. To create such a service, you use a CFC, writing the functions that you want to provide to the service consumers. These functions must have their access attribute set to remote in order to be accessible to Flash consumers.

Here is a simple example of a service:

<cfcomponent>
<cffunction
name="search"
access="remote"
returntype="query"
output="false"
hint="Returns listings matching the search criteria">

    <cfargument name="status" type="string" default=""/>

<!--- code here that generates a query called myQuery --->

<cfreturn myQuery/>
</cffunction>
</cfcomponent>

We could have included the code that queries the database in the service CFC but it is better to separate presentation from data layers and keep well-defined tasks encapsulated in different components. In this way, the core components that access the database can be completely separate from service components that may access them. The service components, knowing that they are services, can offer additional functionality specifically targeted to Flash, such as formatting.

There is another advantage to this approach. It is common practice to keep components instantiated in a scope that spans several requests, such as the application or session scopes. When a Flash Remoting call is made to a component, however, this component is instantiated at that time - and every time a request is made, a new instance of the component is created.

This means that Flash Remoting cannot call an already instantiated component residing in memory in a shared scope. The only way to resolve this issue is to have a service component that differs from the component that does the actual work. When Flash Remoting calls the service component, this can reference the component residing in memory and make the appropriate invocations. For simplicity's sake, this example instantiates ListingGateway.cfc but the source files use the memory-resident CFC approach (see Figure 4).

Because the Search panel sends simple data types that match the types expected by the ListingGateway component, the service can simply pass the same arguments along by using an argumentCollection (see Listing 2).

Name this component ListingService.cfc and save it in the services folders.

Calling the Service
Now that you have created a service, you are ready to call it. Provided that you are running ColdFusion on your local machine, the Flash Remoting gateway is typically located at http://localhost/flashservices/gateway. That is its default address for ColdFusion installations.

Please note that this address might be different if you are using the built-in Web server option (if your Web root is located at http://localhost:8500).

Adding ActionScript to the Flash Form
To call a service from a Flash Form, you must write some ActionScript. You can add any piece of ActionScript code to the form by writing inline statements in the controls' event handlers, such as onClick, or by writing code blocks in functions using the <cfformitem type="script"> tag that has been added in the ColdFusion 7.01 Updater. For readability and easier maintenance, we recommend using functions.

Because you will use this Flash Remoting service several times, we recommend that you store it in a variable that can be used by other functions and controls. Wrap the Flash Remoting setup code that creates the service and stores this variable in a called setUpRemoting():

<cfformitem type="script">
setUpRemoting():Void{

}
</cfformitem>

Inside the cfformitem tag, declare the connection and service proxy as local variables:

//note the gateway address
var connection:mx.remoting.Connection =
mx.remoting.NetServices.createGatewayConnection
("http://localhost/flashservices/gateway/");

var myService:mx.remoting.NetServiceProxy;

Declare an object that handles all the responses:

var responseHandler:Object = {};

Page 2 of 4   « previous page   next page »