Christophe Coenraets, January 26th 2009
In this Test Drive, you run a series of short sample applications that demonstrate the key features of the Spring BlazeDS Integration.
This Test Drive is still work in progress. Please send your feedback to ccoenrae@adobe.com.
If you want to open the source code in Flex Builder, read these instructions to set up your Flex Builder projects.
Open main.mxml in the spring-flex-testdrive/projects/flex/spring-blazeds-101/src directory to look at the source code of the application.
Open the following files in a text editor to look at the source code for the server side of the application:
Note that in this first sample, we use a simplistic DAO implementation with low level JDBC code and no real abstraction. This was done intentionally to provide a bare-bones example that focuses exclusively on the Spring/BlazeDS Integration plumbing. In all the other examples of this Test Drive, we use the JdbcTemplate abstraction of the Spring framework to build the data access objects.
Using RemoteObject, you can directly invoke methods of Java objects deployed in your application server, and consume the return value. The return value can be a value of a primitive data type, an object, a collection of objects, an object graph, etc.
Using the Spring BlazeDS integration, Spring beans are exposed using the typical Spring remoting exporter configuration. See the "product" bean definition in web-application-config.xml.
Java objects returned by server-side methods are deserialized into either dynamic or typed ActionScript objects. In this example, we don't have an explicit ActionScript version of the Product Java class. Product objects are therefore deserialized into dynamic objects. In InSync03 below, we start working with strongly typed model objects.
Open insync01.mxml in the spring-flex-testdrive/projects/flex/insync01/src directory to look at the source code of the application.
Open the following files in a text editor to look at the source code for the server side of the application:
Click here to run the application
Open insync02.mxml in the spring-flex-testdrive/projects/flex/insync02/src directory to look at the source code of the application.
This version is similar to InSync01, but demonstrates how to use the ResultEvent and FaultEvent to have a finer control over RemoteObject calls.
Open insync03.mxml, Contact.as, and ContactForm.mxml in the spring-flex-testdrive/projects/flex/insync03/src directory to look at the source code of the application.
In this version, we work with strongly typed contact objects. The Contact.as class is the ActionScript representation of spring.flex.samples.contact.Contact.java. The [RemoteClass(alias="flex.spring.samples.contact.Contact")] annotation in Contact.as is used to indicate that instances of Contact.as sent to the server should be deserialized as instances of flex.spring.samples.contact.Contact at the server side, and that similarly, instances of flex.spring.samples.contact.Contact retrieved from the server should be deserialized as instances of Contact.as.
Open insync04.mxml in the spring-flex-testdrive/projects/flex/insync04/src directory to look at the source code of the application.
Open insync05.mxml and ContactForm.mxml in the spring-flex-testdrive/projects/flex/insync05/src directory to look at the source code of the application.
This version enables the user of the application to add contacts. In ContactForm, we remotely invoke the create() method of ContactDAO when dealing with a new contact, and the update() method when updating an existing contact.
Open insync06.mxml, ContactForm.mxml, and ContactEvent.as in the spring-flex-testdrive/projects/flex/insync06/src directory to look at the source code of the application.
In this version, ContactForm dispatches events when a contact has been created, updated, or deleted. Other components of the application can register as listeners to these events to perform a specific task when a contact is created, updated or deleted. In this case, the main application registers as a listener to these events and refreshes the contact DataGrid to make sure it reflects the changes made in ContactForm.
Open insync07.mxml and styles.css in the spring-flex-testdrive/projects/flex/insync07/src directory to look at the source code of the application.
Open main.mxml in the spring-flex-testdrive/projects/flex/insync-air-spring/src directory to look at the source code of the application.
In this version we also use the client-side Channel API to programmatically provide the endpoint of the AMF channel. By default, the endpoint is read from services-config.xml at compile time. This means that the compiled application includes a hardcoded value for the AMF endpoint URL, which is not appropriate for real life applications. The client-side Channel API allows you to provide the endpoint URL at runtime. In this version, the URL is now hardcoded in the client code which is not a good solution either. The key, in a real life application, is to obtain that URL dynamically. One approach is to read a configuration file using the HTTPService.
Open companymgr.mxml, Company.as, Industry.as, and CompanyForm.mxml in the spring-flex-testdrive/projects/flex/companymgr/src directory to look at the source code of the application.
Open the following files in a text editor to look at the source code for the server side of the application:
This application is similar to inSync, but demonstrates object associations: the Company class has a property of type Industry.