At the end of the second article in this series, we ended up with a working application but it was not really ready for the real world because it had one major flaw: the URL of the AMF endpoint was hardcoded in the client in such a way that it was impossible to change after compilation and very hard to handle several environments (dev, test, prod). The solution to that problem is to integrate dependency injection into the mix.

Now there are a lot of such frameworks for Flex/ActionScript applications, including Parsley, Swiz, Cairngorm, etc. But I’ve never been a big fan of those big MVC frameworks that impose their own interpretation of the MVC pattern and completely limit the initial capabilities of Flex itself. For me, the Flex framework itself is clean enough that you don’t need all that overhead and it’s better to use a non-intrusive framework like Spring ActionScript. So that’s what we are going to do.

First off, go download the latest release of Spring ActionScript with its dependencies. Unzip this distribution and copy all four as3commons libraries under lib/ into the “libs” directory of your Flex project. Do the same with spring-actionscript-core-1.1.swc under dist/. You should now have 5 SWC’s in your libs folder:

Now, like its Java big brother, Spring ActionScript configures itself thanks to an XML application context file. And we are going to configure our AMF channel and our channel set in that file. We don’t want to embed that file into our Flex application because if we do so, we won’t be able to change it dynamically. And we want its content to be synchronized with the current environment. That’s why we will use a little trick here.

First, in your Grails application, create a new controller called org.epseelon.todolist.controllers.ApplicationcontextController. To do that, you can use the following command: “grails create-controller org.epseelon.todolist.controllers.Applicationcontext”. You can also use IntelliJ’s shortcuts: right-click the grails-app/controllers directory and choose “New Grails Controller”:

And in the dialog that appears, enter “org.epseelon.todolist.controllers.Applicationcontext”:

Now you can leave the ApplicationcontextController class as it is. But if you created your controller with IntelliJ IDEA, you should have a new index.gsp file under grails-app/views/applicationcontext. We are going to modify that file and use the fact that Grails can render XML templates and HTML templates in the same way:

[sourcecode language=”xml”]
<%@ page import="org.codehaus.groovy.grails.commons.ConfigurationHolder" contentType="text/xml;charset=UTF-8" %>

[/sourcecode]

The first thing to notice here is the content type of this GSP, which is text/xml and not text/html. We also import ConfigurationHolder which will allow us to user the environment-specific server URL as defined in grails-app/conf/Config.groovy without having to load it from the controller. Our AMF endpoint URL is now configured in the second argument of the constructor for the first bean. What this application context does is that it configures an AMF channel and a channel set that we will be able to inject into our Flex application. But you can already test this controller by starting your Grails application and going to http://localhost:8080/todolist/applicationcontext.xml. You might wonder where this extension comes from: Grails uses the extension as an indication of the context type that is expected as a response, which makes it possible get different response formats from the same controller action just by changing the extension. Here we are just using the fact that by default, an empty action renders a GSP view with the same name as the action (index) and the content type declared in the GSP corresponds to the one requested.

The next step is to load that application context into our Flex application. To do that, let’s add a couple of event handlers to our s:Application element:

[sourcecode language=”xml”]



… [/sourcecode] We add 2 variables, contextURL et channelSet. We also modified the currentState attribute of our application to consider the possibility that channelSet might not be initialized yet when currentState is determined. In the preinitialization handler, we load the contextURL, which is the URL of our applicationcontext.xml file from a mysterious parameters map. We will see later where this parameter comes from. When the application is completely loaded, we bootstrap Spring ActionScript by creating an XMLApplicationContext configured with the asynchronously-loaded application context. And when the context is completely loaded, we manually inject the channelSet bean into our channelSet variable, and since we are now connected to the server, we can reload the tasks. Of course, we also have to update our TodoListService declaration to remove the manually configured channel set and replace it with this Spring ActionScript injected one: [sourcecode language=”xml”] [/sourcecode] Now, let’s get back to this mysterious contextURL parameter. Once again, we don’t want the location of our applicationcontext.xml file to be hardcoded into our application, otherwise we are just moving the problem. So the idea here is to use what is to inject a flash variable from the HTML file that embeds our Flex application. We will take this opportunity to get rid of the default HTML template generated by Flash Builder since chances are we will want to integrate our application into a GSP anyway. So now copy the content of web-app/Main.html into grails-app/views/index.gsp and modify it like the following: [sourcecode language=”html”]

[/sourcecode] The first modification is on line 41: var flashvars = {ContextURL:”applicationcontext.xml”}; The second modification is on line 79: Both of these lines to the same thing, but the second one is used when javascript is disabled in the browser. Those lines assign a value of “applicationcontext.xml” that is the URL of our application context configuration file relative to the url of our main page. And that’s the ContextURL flash variable that is then retrieved in the Flex application. The loop is now complete. Now we can disable HTML Template generation in Flash Builder: right-click your Flash Builder project and choose Properties: In Flex Compiler section, uncheck “Generate HTML wrapper file”: Click OK and confirm the next dialog box. Don’t worry again, nothing will be deleted. Now you can go back to your Grails application and delete the following file: web-app/Main.html If you restart your Grails application and go to http://localhost:8080/todolist, you should now see our todo list with our 3 test tasks loaded. You can even log in and create a new task. The full code of this tutorial is available on GitHub. For now, I don’t see what I could add to this sample application. I’m going to use it myself as a starting point for some real world project of mine and I’ll see if I discover new things that are worth sharing. Make good use of this and enjoy this great combination of highly productive technologies.