Adobe® LiveCycle® Data Services ES 2.6 Developer Guide

The fill-method approach

The fill-method approach is designed for simple applications. You declare individual methods by using XML elements named fill-method, sync-method, and get-method in a destination definition in a configuration file. You use these elements to map arbitrary methods of an assembler as fill and sync methods. The method names that you specify in these elements correspond to methods in the assembler class. These methods are called when data operations occur on a Flex client application. Never declare a sync-method element if the items are read-only.

If the signature of the fill request sent for a client does not match a fill-method element, the Data Management Service calls the fill() method defined in the assembler if it implements the flex.data.assemblers.Assembler interface.

When you use fill-method elements, each fill method is identified by the types of parameters declared in a corresponding fill-method element. Do not declare two fill methods that take the same types of arguments or an error occurs when you try to invoke the fill method. Another important consideration is that a null value passed to a fill method acts like a wildcard that matches any data type. If you expect to use many fill methods, assign them a name or identity as the first parameter to uniquely identify the query you want to perform. You can then initiate queries with different names within your fill method.

You can implement any number of fill methods to fill a client-side ArrayCollection object with data items. You specify fill methods in the fill-method section of the destination; each of these methods is assigned as a fill method that can accept an arbitrary number of parameters of varying types and returns a List object. The data types must be available at run time. Any call to a client-side DataService component's fill() method results in a server-side call to the appropriate Java fill method with the parameters that the client provides.

In a sync-method element, you specify a method that accepts a change list as its only input parameter. You can choose to implement the sync method as a single method that takes a list of ChangeObject objects, or you can extend the AbstractAssembler class and override the updateItem(), createItem(), and deleteItem() methods.

The change list is a java.util.List implementation that contains objects of type flex.data.ChangeObject. Each ChangeObject in the list contains methods to access an application-specific changed Object instance. Each ChangeObject also contains convenience methods for getting more information about the type of change that occurred and for accessing the changed data members. Only use the iterator in this list to iterate through the ChangeObjects. Use of the get method in the list is not allowed. The flex.data.ChangeObject class is included in the LiveCycle Data Services ES Javadoc API documentation.

Note: The compiled assembler class and any other required classes, such as a DAO class, must be available in the web application classpath. When you compile code that uses LiveCycle Data Services ES Java APIs, you include the messaging.jar and flex-messaging-common.jar files in your classpath.


 

Send me an e-mail when comments are added to this page | Comment Report

Current page: http://livedocs.adobe.com/livecycle/8.2/programLC/programmer/lcds/dms_custom_assemblers_4.html