Epseelon

Grails Flex Integration, version 1.0

Ever since I discovered Grails, I’ve never stopped looking for the best way to make it work with Flex (I guess for me, the search was NOT over). Why so? Simply because the less time we spend connecting components, mapping objects with the database and dealing with boilerplate code, the more time we have for building gorgeous user interfaces. As for usual web suspects like JSF, GWT, GSP and other HTML/JS-generators, they have never been the best solution for me.

So how do we get Grails and Flex to work together? Well, Grails uses Spring behind the scenes and it is maintained by SpringSource, who also happen to be behind Spring BlazeDS integration in partnership with Adobe. So everything seems to be there… but there’s a problem. The best way to integrate any technology with Grails is via a plugin. Unfortunately the Grails Flex plugin is very old (it does not use Spring BlazeDS integration, but an old custom workaround) and only experimental. There is also a GraniteDS plugin for Grails, but GraniteDS is an alternative to BlazeDS, so it’s not the mainstream way of doing things. And Graeme Rocher has started working on a Spring BlazeDS integration plugin based on the old Flex plugin, but it was never released. Hmmm…

I know, when you’re unhappy with an open source project, when you feel it’s missing something, the better way to help is to do it yourself and share it with the community. But the problem is, although I love using Grails, I’ve never developed a plugin for it before. And this Flex plugin doesn’t seem like an easy one to start with. That’s why I decided to do things differently.

A few months ago, I published an article about Spring, Hibernate, BlazeDS and Flex. This article was very popular, both on my blog and on Adobe Developer Network. But new versions of Maven, Flex and Flexmojos have been released since then, so the article is a little bit outdated now. So why not use this opportunity to do an update?

So here we go. In the following file, there is the full todolist-grails project, that you can also find on GitHub (this is my first Git project by the way). This first version is merely a proof-of-concept. It’s not a plugin, it’s a traditional Grails application with Flex infrastructure added to it.  And because I didn’t find a way to integrate Flex compiler with Grails yet, I’m still using IntelliJ Idea to build the Flex part. Still, I’m publishing it as it is because I hope people will help me improve it incrementally.

So if you can help me improve this project and create a Grails plugin out of it in order to automate Flex compilation, integrate Spring Security, generate DTO’s automatically, you’re more than welcome. Let’s get this thing rolling.

Sebastien

, , ,

13 responses to “Grails Flex Integration, version 1.0”

  5. Very cool. I’m cloning this right now so I can look into this. I would love to help out where I can. I must say I’m rather impressed with how much easier integrating Flex with Java has been since the Spring BlazeDS integration stuff has been released.

    Reply

  6. “…they have never been the best solution for me”

    Hi, i started learning grails and i’m thinking in using flex for my next app frontend but i’m concerned about the deploy / performance of flex apps. Could you explain the cons that make you choose flex besides say grailsUI?

    Thanks.

    Reply

    • The first reason is that most of the web applications I’m working on are applications, not websites. And web technologies like HTML, CSS and Javascript were never meant to build applications. Now I know that we’ve tinkered a lot in the past few years with all these Javascript/HTML generators like GWT, JSF, GSP and GrailsUI, but for me it’s just that: tinkering. And you still end up trying to do new stuff with old stuff behind the scenes, which I don’t find clean alone (let alone performant). Flex on the other hand is a natural fit for this kind of applications. You don’t need to worry about cross-browser issues (well… for the most part), you get a consistent user experience and the programming model is much much cleaner: in the end, my MXML and Actionscript get compiled to run on a very good VM and all is good. Now I’m not saying Flex is the silver bullet, but it sure is adapted to the kind of applications I’m dealing with right now (administration back-office), and I know it pretty well too. Plus, there are some very interesting things coming up in Flex 4 that make me think I was right to invest in that technology.

      Now I’ve tried GrailsUI, but it’s still very limited. It offers an interesting component palette but that’s not enough to build up a whole presentation layer. I need something to happen when I click a button, and for that, I’m back to Javascript and links, right? I don’t like this way of doing things. I’ve been raised with event-driven stuff and controls and remoting, not with links, REST, div’s and JSON. And once again I know there are some Javascript alternatives that abstract those things up, but why use those layers of abstractions when you can program directly for a runtime that is available on 98% of machines?

      But at the end of the day, it’s all about getting things done, so I’m for using the tools that you master the most. I’m not saying that Flex IS better, I’m just saying it SEEMS better to ME.

      Reply

    • I think we should stay pragmatic and not try to put too much stuff in here. I’m a big Maven fan, but it’s a whole different beast. I don’t think we should depend on it for the build to work. First let’s add Flex compilation to the Gant build, and then we can add it to the grails maven structure. In addition, from what I’ve read, the whole dependency mechanism will change in Grails 1.2, to be closer to what Maven does. The same for Jetty 7: do we need it for the Flex plugin to work?

      The risk is that if we try to push too many things, it will fail like all other previous trials. So I’d rather keep it simple.

      Reply

  9. Hello Sebastien,
    I am very interested in the flex (especially flex builder) with grails integration.
    Unfortunately I am more familiar with grails than with flex.
    Is it possible to start the flex build process (i.e. the compilation) from the command line?
    In this case one could utilize the grails build event mechanism to invoke the flex compilation.
    That is you could add a file called “_Events.groovy” into grails’ script directory that contains something like this:

    eventCompileStart = {
    // This closure is called when compilation starts.
    // See http://grails.org/Scripting%20events for the documentation of scripting events
    // here we could call the flex compilation process
    // or define appropriate ant targets
    }

    Reply

    • I’ve tried that before. Unfortunately, it seems that hooking Flex build into Grails is cumbersome at best, not a very good idea at the very least. Flash Builder 4 really makes a difference in terms of productivity and it makes even more sense to me now to develop your Grails server and your Flex applications as separate projects, and treat your Flex client as a simple SWF from a Grails standpoint. That said, if you manage to hook Flex ant tasks into Grails build with Gant, it will certainly be an excellent alternative for people who don’t want to use Flash Builder.

      Reply

Leave a Reply

%d