The application above doesn't cover all use cases of the FDS API. We tried to keep it as small as possible for one reason: to enable metadata-based code generation. Ultimately, it will be entirely up to you which code you'd elect to generate by modifying the DAOFlex templates. Finally, we present the listing of the ActionScript class EmployeeDTO that our collection uses in communicating with the Employee destination:

package com.theriabook.datasource.dto
{

    [Managed]
    [RemoteClass(alias="com.theriabook.datasource.dto.EmployeeDTO")]
    public dynamic class EmployeeDTO
    {

       // Properties
       public var EMP_ID : Number;
       public var MANAGER_ID : Number;
       public var EMP_FNAME : String;
       public var EMP_LNAME : String;
       public var DEPT_ID : Number;
       public var STREET : String;
       public var CITY : String;
       public var STATE : String;
       public var ZIP_CODE : String;
       public var PHONE : String;
       public var STATUS : String;
       public var SS_NUMBER : String;
       public var SALARY : Number;
       public var START_DATE : Date;
       public var TERMINATION_DATE : Date;
       public var BIRTH_DATE : Date;
       public var BENE_HEALTH_INS : String;
       public var BENE_LIFE_INS : String;
       public var BENE_DAY_CARE : String;
       public var SEX : String;

       public function EmployeeDTO() {
       }
    } //EmployeeDTO
}

Creating Assembler & DTO Classes
The time has come to work on the Java side, which is a rather tedious process, so we'll gradually go top-down.

Our first stop is an Assembler class that the FDS Employee destination should map to. As the Flex documentation suggests, you can implement the methods on your Assembler class in several ways:

• Extend flex.data.assemblers.AbstractAssembler and override the fill(), getItem(), createItem(), updateItem(), and deleteItem() methods as needed;
• Configure these methods via XML definitions against a class that doesn't extend the AbstractAssembler class;
• Or a combined approach, where methods defined via XML declarations are used if defined, otherwise the AbstractAssembler methods are invoked.

We'll take an XML approach that lets us declare a so-called sync-method. The XML contract of the destination's sync-method prescribes that it accepts a single parameter: a List of flex.data.ChangeObject elements. We find it convenient to control how we want to process data changes. In particular, we'd like to maintain the following order: all deletes, then all updates, and then all inserts. After all, if the user deletes a record for an employee with EMP_ID= 123 and then inserts a new record with EMP_ID=123, we certainly wouldn't want our sync-method to issue the INSERT, followed by DELETE FROM employee WHERE EMP_ID=123 during the batched FDS data modifications.

Let's keep in mind that our ultimate focus is the metadata-based code generation. Should you decide to have your Assemblers as descendants of the AbstractAssembler, you'd have the liberty of modifying the corresponding DAOFlex template.

Listing 6.3 presents the complete XML describing the destination Employee. Under the default configuration scenario, this XML would go inside the <services> node of the flex-data-services.xml file, located in the WEB-INF/lib/flex folder of your Web application.

We set com.theriabook.datasource.EmployeeAssembler as the exact name of the class mapped by our destination, with the methods java.util.List getEmployees_fill(java.util.Date dt) and the List getEmployees_sync(List lst) acting as the fill and sync methods respectively.

Even though XML doesn't explicitly declare that that the fill-method returns a List or that the sync-method takes a List, this is a part of the XML contract for Assembler classes in destinations:

<destination id="Employee">
    <adapter ref="java-dao"/>
<properties>
    <source>com.theriabook.datasource.EmployeeAssembler</source>
    <scope>application</scope>
    <metadata>
      <identity property="EMP_ID"/>
    </metadata>
<network>
<session-timeout>0</session-timeout>
<paging enabled="false"/>
<throttle-inbound policy="ERROR" max-frequency="500"/>
<throttle-outbound policy="ERROR" max-frequency="500"/>
</network>
<server>
    <fill-method>
    <name>getEmployees_fill</name>
    <params>java.util.Date</params>
    </fill-method>
    <sync-method>
      <name>getEmployees_sync</name>
    </sync-method>
</server>
</properties>
</destination>

The structure of the EmployeeAssembler Java class is pretty straightforward. This class delegates the actual data retrieval and update of the data store to EmployeeDataServiceDAO class, which we'll discuss next:

package com.theriabook.datasource;
import java.util.*;

public final class EmployeeAssembler
{
    public EmployeeAssembler()
    { }

    public final List getEmployees_fill(Date startDate) {
      return new EmployeeDataServiceDAO().getEmployees(startDate);
    }

    public final List getEmployees_sync(List items) {
      return new EmployeeDataServiceDAO().getEmployees_sync(items);
    }

}

The chapter then leads the reader line by line through the entire set of programming tasks required to build a fully functional create-retrieve-update-delete (CRUD) application based on Employee Data Service destination. Once the job is well-know, the reader is invited to automate it once and for all. Here is one more fragment.

Introducing Metadata
Let's look at the snippet from the XML file generated by the DAOFlex utility - Employee.xml. Please note the name of the Java package - com.theriabook.datasource, the name of the Assembler's fill method - getEmployees(), names on the transferring structures on the Java and ActionsScript side, both pointing to array of com.theriabook.dto.EmployeeDTO objects, the name of the connection pool - jdbc/theriabook, and the name of the method's parameter - startDate:

<?xml version="1.0" encoding="UTF-8"?>
<WEBSERVICE NAME="Employee" PACKAGE="com.theriabook.datasource" TYPE="DAOFlex" >
<SERVER LANGUAGE="Java" MODE="JEE">
<SQL ACTION="SELECT"
NAME="getEmployees" POOL="jdbc/theriabook" SCOPE="public"
ASTYPE="com.theriabook.dto.EmployeeDTO[]" JAVATYPE="com.theriabook.
dto.EmployeeDTO[]"
>
<PARAM IN="Y" INDEX="1" JAVATYPE="Date" NAME="startDate"/>
</SQL>
</SERVER>
</WEBSERVICE>

Starting at this point, we'll be working our way through this XML while building the complete XSL stylesheet from scratch. Once we make this stylesheet, it'll be capable to manufacture any DataServiceEmployeeDAO, DataServiceDepartmentDAO, etc. - as long as we have the metadata XMLs like the above one. You're probably wondering at this point: "What's the input of the DAOFlex that allows it to generate this XML?"

The input for DAOFlex is an annotated Java class, like the one presented in Listing 6.11:

package com.theriabook.datasource;
import java.util.Date;
import java.util.List;
/**
* @DAOFlex:webservice pool=jdbc/theriabook
*/
public abstract class Employee {
/**
* @DAOFlex:sql
* sql=select * from employee where start_date < :startDate or start_date=:start_Date
* transferType=com.theriabook.dto.EmployeeDTO[]
* updateTable=employee
* keyColumns=emp_id
*/
public abstract List getEmployees(Date startDate);
}

Reference

Rich Internet Applications with Adobe Flex and Java: www.riabook.com