Accessibility

Table of Contents

Using ColdFusion with Flex – Part 1: Creating and running a contact manager application

Understanding the application

This simple application demonstrates some important concepts and techniques, which I've outlined in the following sections.

ColdFusion code

The ColdFusion components correspond closely to the Java classes used by the Java assembler (see C:\fds2\jrun4\servers\default\samples\WEB-INF\
src\samples\contact
):

  • Contact.cfc is the value object used to represent the data from the table. There is one object per row in the database. The translation layer uses the alias attribute in the <cfcomponent> tag to determine the name of the ActionScript class into which the CFC is translated.
  • ContactAssembler.cfc is the main interface between ColdFusion and Flex Data Services. It uses the Data Access Object (DAO) component to perform data operations:

    • fill returns an array of contacts and can take optional parameters to return a specific subset of the data. If fill does not receive any arguments, it returns all the data.
    • count takes the same arguments as fill. You can use count for user interface purposes to return the number of records that fill returns with the same arguments. The Contact Manager application does not use count.
    • sync accepts an array of Flex change objects, which are Java objects that describe the changes a Flex client requests to the database. All create, delete, and update operations call this method, which then loops over the array and calls the private methods doCreate, doUpdate, and doDelete, based on the type of the change object.
    • get returns a single contact and takes as its argument the primary key of the table, in this case, the contactId.
  • ContactDAO.cfc is the DAO that performs all the operations on the database table:

    • read returns the entire data set if not passed an argument or, if param is provided, limits the result to records whose first or last name contain the parameter string.
    • create inserts a new record in the table. It uses a transaction so it can reselect the inserted row to get the ID for the new record. It then sets this value in the bean. This is an important step because Flex needs this value to keep track of this record.
    • update modifies an existing record in the database. It uses a WHERE clause to insure the data it is changing matches the view of the data on the client. If the application does not successfully update a record, the application throws a user-defined conflict exception, which is caught in the assembler CFC and then marks the Flex change object as having a conflict.
    • delete removes a record from the database. It also uses a WHERE clause to ensure that the record being deleted matches the data on the client. If not, it also throws a conflict error, so the assembler CFC can mark the change as having a conflict.
    • count performs the same select as fill but returns the number of records instead of the actual data.

Flex code

The Flex code is included as a sample application, contactmgr.mxml, in Flex Data Services 2:

  • The contacts ArrayCollection and the contact variable are labeled [Bindable].
  • The initApp() function creates the DataService object (ds) and invokes the first call to fill(). This populates the contacts ArrayCollection with data.
  • The updateContact() function invokes the commit() operation on the DataService object. This invokes the sync CFC method with a Flex change object generated by the server.
  • The searchContacts() function invokes the fill operation, passing it the contents of the search box. This is then passed to the fill CFC method, which uses it to restrict the records returned.
  • The conflictHandler() function is invoked when a conflict occurs between the data on the client and the data on the server. In this simple example, you accept the server version of the data and alert the user of that fact.