Mobile, Cloud, HTML, JavaScript, Java, PHP, Flex
I updated my Salesbuilder sample Flex/Adobe AIR application with a couple of new interesting features:
A typical source of confusion when developers start working with RemoteObject or other BlazeDS/LCDS related classes is where and most importantly *when* the configuration of your services is being read.
The question often arises after an application stops working when you move it to another server. This is one of the most frequently asked questions related to BlazeDS and LCDS, so I figured I would answer it here. There is nothing really new in this post, but hopefully this will be a good point of reference.
When you create a new BlazeDS or LCDS project in Flex Builder, you are typically told to select J2EE as the “Application Server Type” and then check “use remote object access service”. This adds a compiler argument pointing to the location of your services-config.xml. If you check the Flex Compiler properties of your Flex Builder project, you’ll see something like this:
-services “c:\blazeds\tomcat\webapps\samples\WEB-INF\flex\services-config.xml”
When you then compile your application, the required values of services-config.xml are baked into the SWF. In other words, services-config.xml is read at compile time and not at runtime as you may have thought intuitively. To abstract things a little bit, you can use tokens such as {server.name}, {server.port}, and {context.root} in services-config.xml. However, {context.root} is still substituted at compile time, while {server.name} and {server.port} are replaced at runtime using the server name and port number of the server the SWF was loaded from (which is why you can’t use these tokens for AIR applications).
In part 1 of this series, we saw how Flex AS allows you to externalize the configuration and the wiring of objects. In part 2, we discussed how you can “autowire” view properties. We intentionally kept the example simplistic by directly injecting the contact RemoteObject into the views. In real life, however, you generally don’t want to tie your views to a specific service implementation… The views should be independent from your data access strategy: RemoteObject, HTTPService, WebService, mock service, etc.
To satisfy this requirement, we will create an IContactService interface, and two classes that implement that interface:
For the purpose of this sample application, IContactService is defined as follows:
In the first part of this series, we looked at how the “Spring ActionScript” framework can help you externalize the configuration and the wiring of your components, and how you can easily obtain configured objects using applicationContext.getObject().
In this second part, we will discuss how you can make these objects available to the views of your application without tightly coupling these views to the framework, and without passing references around through potentially many levels of view containment.
We will build the “Spring ActionScript” version of the InSync contact management application I often use in this blog to explore new technologies. The application has two views: MainView and ContactForm. Both need a reference to a contact RemoteObject to work.
NOTE: This example is intentionally kept simple. In a more partitioned application, you may want to pass a more abstract controller around as opposed to a specific RemoteObject. We will use this approach in part 3.
The views could use applicationContext.getObject() to access their dependencies (in this case the contact RemoteObject), but this approach has a number of problems:
So, instead of the views instantiating or looking up their dependencies, a better approach would be to “inject” these dependencies into the views.
Unlike Swiz, “Spring ActionScript” doesn’t currently have built-in support for an [Autowire] annotation, but Christophe Herreman seems to imply that this feature is coming, and in the meantime, he provides some sample code to support “Spring ActionScript”-powered autowiring in your application. Using this custom code, the inSync application looks like this:
UPDATE: This version of the Test Drive is now obsolete. I posted a new version of the Test Drive for the RC1 build of the Spring / BlazeDS integration project here.
I updated my Test Drive for the M2 build of the Spring / BlazeDS integration project.
The Test Drive now includes a sample demonstrating the integration with Spring Security (the key new feature in M2). The Spring configuration file has also been updated to use the new simplified XML-namespace-based configuration.
As always, I’d love to hear your feedback and your ideas to improve this Test Drive.
Christophe
The “Spring ActionScript” framework (formerly known as Prana, and brainchild of Christophe Herreman) is being built as the ActionScript version of the Spring IoC framework hugely popular in the Java world. It is also part of a growing number of Flex frameworks that revolve around the Dependency Injection approach (the list also includes Swiz and Mate).
I recently spent some time exploring “Spring ActionScript”. There aren’t a lot of resources available yet, so I figured I would contribute my own exploration.
Note: Also, to avoid confusion, this project is independent from the Spring/BlazeDS integration project I have been writing about a lot lately. These two projects could however complement each other nicely.
In this first post, I’ll cover the basics… Imagine you have an application that uses RemoteObject to access the back-end of your application. Unless your application is made of only a couple of components and will forever communicate with the same server, there are two issues you’ll have to deal with early on:
RSS