Understanding data management adapters
An adapter is responsible for updating the persistent data store, or in-memory data in the case of the ActionScript object adapter, in a manner appropriate to the specific data store type. The Java adapter delegates this responsibility to the assembler class.
The Java adapter and the ActionScript object adapter are included with Adobe LiveCycle Data Services ES. The Java adapter passes data changes to methods available on a Java class, called a Java assembler, which handles interaction with the underlying data resource.
You use the ActionScript object adapter when a Flex client application is the only creator and consumer of transient data objects and there is no back-end data resource. The Data Management Service uses the ActionScript object adapter to manage objects in the server's memory.
The Java adapter lets you synchronize Java objects on the server with ActionScript objects on the client. This adapter passes data changes to methods available in a Java class called an assembler. The following table describes the types of Java assemblers:
|
Assembler |
Description |
|---|---|
|
Custom assembler |
Use a custom assembler if you have sophisticated data models and understand Java server-side code. This type of assembler offers the most flexibility, but is also the most complex to use. For more information, see Custom assemblers. |
|
SQL assembler |
The SQL assembler is a specialized assembler that provides a bridge from the Data Management Service to a SQL database management system. Use this type of assembler if your database data model does not have complex object relationships and you want to expose that data model to MXML without writing Java server-side code. For more information, see Standard assemblers. |
|
Hibernate assembler |
The Hibernate assembler is a specialized assembler that provides a bridge from the Data Management Service to the Hibernate object-relational mapping system. Use this assembler if you do not want to write a custom assembler, you require access to database objects, you are using or have used the Hibernate object-relational mapping system, and you are comfortable with Java. For more information, see Standard assemblers. |
When using the ActionScript object adapter, you can use any field in an ActionScript object to provide a unique identity property in the identity element of the destination's metadata section. You can establish a composite identity by specifying more than one identity property. If unspecified, by default the uid property of the ActionScript object is the identity property.
The following table describes each of the destination elements that are specific to the ActionScript object adapter. These elements are children of the server element.
|
Element |
Description |
|---|---|
| create-security-constraint |
Applies the security constraint referenced in the ref attribute to the create requests. |
| read-security-constraint |
Applies the security constraint referenced in the ref attribute to fill requests. |
| update-security-constraint |
Applies the security constraint referenced in the ref attribute to update requests. |
| delete-security-constraint |
Applies the security constraint referenced in the ref attribute to delete requests. |
| count-security-constraint |
Applies the security constraint referenced in the ref attribute to count requests. |
The following destination definition, which you create in the data-management-config.xml file, specifies a single identity property. For more information about destinations, see About Data Management Service destinations.
<destination id="notes">
<adapter ref="actionscript"/>
<properties>
<metadata>
<identity property="noteId"/>
</metadata>
</properties>
</destination>
Each item must have a unique identity property and there is no back-end data resource that automatically creates identity properties. Therefore, for an application in which you require an ArrayCollection of data items, you must generate item identity properties on the client when you create managed objects. The code in the following example uses the mx.utils.UIDutil.createUID() method to generate a universally unique customer.custId property to serve as the identity property. You could also specify custId as the identity property in a destination definition in the data-management-config.xml file.
private function newCustomer():void {
dg.selectedIndex = -1;
customer = new Customer();
customer.custId = mx.utils.UIDutil.createUID();
}
The following example shows a client application that uses the ActionScript object adapter to persist a single data item if it doesn't already exist in a TextArea control across all clients. When the server is stopped, the data is lost because there is no back-end data resource.
<?xml version="1.0"?>
<!-- ds\datamanagement\ASAdapter.mxml -->
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
height="100%" width="100%"
creationComplete="initApp();">
<mx:Script>
<![CDATA[
import mx.data.DataService;
import mx.rpc.AsyncToken;
public var noteObj:Object = new Object();
[Bindable]
public var getToken:AsyncToken;
private var ds:DataService;
private function initApp():void {
ds = new DataService("notes");
ds.autoCommit = false;
noteObj.noteId = 1;
noteObj.noteText =
"Type your notes here and share them with other clients!";
// The first getItem method parameter is the identity property of noteObj.
getToken = ds.getItem({noteId:noteObj.noteId}, noteObj);
}
]]>
</mx:Script>
<mx:Binding source="log.text" destination="getToken.result.noteText"/>
<mx:TextArea id="log" width="100%" height="100%" text="{getToken.result.noteText}"/>
<mx:Button label="Send" click="ds.commit();"/>
</mx:Application>