An Ajax and Flex Architecture on Grails

When working with Grails and Adobe Flex, there are three possible alternatives:

a) Pure Flex – write the application like an AIR application. Your entire site is a big Flex file ( see the ufc 93 site )

b) Pure HTML + AJAX – do not engage Flex at all. Use AJAX to power all the dynamic elements on the page ( like Google Maps)

c) HTML + AJAX + Flex – Write certain components in Flex, leave other components in either static HTML or Ajax.

In this post, I will try to show why option 3 is always the best and overcomes the shortcomings of both Flex and Ajax.

Things HTML/AJAX does better than Flex/Flash

Grails Support:

Grails hearts Ajax. The way in which many of the templates and tags in the toolkit are built support the generation of content in HTML and Ajax form, but do not yet do so for non-HTML content.

The Flex plugin, while incredibly powerful, still lacks much of the functionality provided via Grails plugins.

( One of my new year resolutions is to actually devote some time contributing to this plugin, and my top items are functional testing support via flexunit and automated CRUD generation. Hopefully, with the release of Grails 1.1. and it’s promise to decouple view technologies and the funcional testing plugin, these tasks might be easier )

Search Engine Optimization:

Google crawlers are built for HTML. Despite Adobe’s claims of better SEO support, pure Flex sites will never be indexed as well as pure HTML pages. There is certain content that you want search engines to find to make your site ding whenever these terms are sought. While Flex does try to improve the navigation of pages with the browserManager component, your site is still not properly indexed in a pure Flex/Flash approach.

Keeping product information, press releases or trackback links within pure Flex sites without also putting them in an alternative content ( like <noScript> ) section is just bad practice.

Content Submission

Uploading content to a server using Flex is just painful. There are cross-browser compatibility issues. File upload doesn’t always work in Mozilla and Tomcat. The security mechanism requires you to have a PhD in guessing what Adobe wants to get right.

The Grails built-in validation mechanism only really works in HTML out of the box, and while there is power in doing validation in the client-side via Flex, you still need to do almost the same amount of work to get the data back into the server. When it comes to publishing data into the server, it makes sense to just do it in HTML / AJAX. 

Flash Player 10 and Flex 4 does promise some changes to content submission. It might make content upload in Flex appealing by allowing features like image preview and batch upload. But today, it makes sense to keep file upload and form posting in web applications simple via Ajax and HTML Forms.

Security

Implementing security in Grails also seems to be tightly bound to a HTML way of thinking. Authentication plugins in Grails usually don’t foresee the need to provide non-HTML based views and rely heavily on tokens stored on http sessions, which might not be available to the Flex clients. Doing web service authentication with Grails and Flex is still messy and unclear. I can’t just take the Jsecurity plugin and say “now, go work with web services”, specially when much of the authentication schemes are bound to URL mappings, which are not managed by the server in a pure Flex implementation.

Third Party Integration

It might sound ridiculous, but Flex struggles with even the simplest display of HTML. For a recent project, our third party provider gave us an html site that we tried to integrate into a pure Flex site, and it was just hell. The UI elements would be in the wrong place, the embedded HTML would overlap the Flex dropdowns, links wouldn’t work, JavaScript would wonk out. It was just not fun.

Keeping third party elements in HTML pages is much nicer. First, there are a ton more components available, and they usually behave well across browsers. Captcha libraries, Share This Page Links, Ad keywords all seem to work better in HTML than trying to put them into Flex / Flash.

Things that Flash/Flex does better

Better components

Compared to standard HTML, Flex simply has better components. Even compared with javascript frameworks like Dijit, the wide variety of out of the box components written both in Flex and Flash makes it a better choice for building things like navigation elements, flexible dropdowns and sliding components with visual wow.

Skinning / Cross Browser Compatibility

Flex skinning is simply more consistent and less prone to fits from different browsers. This alone makes the lives of CSS designers simpler, since they are not wasting time making sure that things work across six or seven different browsers — the case today for CSS.

Versatile data filtering, sorting, etc.

One of the key strengths of Flex lies in the way in which data can be displayed in many different ways without reloading the browser. This rich client capability makes searching and filtering lists, reordering data and moving content around much easier than in a traditional Ajax table. The native XML support baked into Flex means less mistakes and more powerful data display. When displaying content that is highly dynamic ( stock quotes, grades, etc ), Flex is the way to go.

Ease of Development

Flex Builder and the Flex profiler allow developers to test and build applications in a much nicer way than any of the tools provided by the HTML / Ajax World. The integrated environment also means less mistakes.

More over, the marriage of Javascript and HTML feels tacked on. Manipulating Div content and innerHTML files works well, but is less elegant and much more error prone than simply being able to bind a component to a variable, which you can do easily in Flex. Flex has had enough time to learn from the mistakes of JavaScript. Having worked with JavaScript and DHTML for over 10 years, it’s refreshing to not resort to clever hacks to get work done.

Graphics API

Flash has an incredible Graphics API, which is available for Flex. For a recent project, our designers decided to make each button a different color based on the page in which the user was in. Instead of generating a different button graphic for each color, we simply applied a ColorTransform to a desaturated background, programmatically changing the appearence of the button on each screen. This would be impossible to do in HTML and JavaScript in a way that would work across all browsers.

Usability

Flex has better support for complex interactions. Drag and drop support in Flex is unparalleled and very simple to implement ( takes about 10 lines of code ).  What’s even cooler is that I could write an Adobe Air container for the desktop, and actually drag and drop content from my online application to the desktop. So I could add a virtual grocery shelf on my browser, and drag and drop cans of food into a shopping cart application I have on my desktop, for example. Flex  blurs the Browser/Desktop boundary, which is impossible with Ajax/HTML.

Defining An Ideal Infrastructure

I hope that by now you can see how there are some pieces that are better built in Flex, and others that make more sense to keep in HTML.

When choosing alternatives and considering the list above, this is what I would do:

HTML/AJAX

  • Authentication / permissions / user logon
  • Navigation between pages ( Url Mappings )
  • Static Elements that need to be Search Engine Optimized ( Press Release, News, Job Postings )
  • Forms / Content Submission ( Sign up for newsletter, change picture )
  • Pages / Content from a third party website ( YouTube videos, addThis Share links, ad networks )

FLEX/Flash

  • Complex data presented in a table or a tree format ( Car specifications, sports stats )
  • Animations ( stock charts, navigation menus )
  • Things that need to be interacted with ( maps, drag and drop lists )
  • Image lists and slide shows
  • Things that need to look good or have complex interactions ( fades, blur ins, highlighting )

In sum, there are things that require much less effort in Flex, and some that require much less effort with HTML / Ajax. Instead of religiously defending one architecture over another, a platform like Grails allows us to have the best of both worlds. Mix and match to maximize development effort and programmer joy.

6 thoughts on “An Ajax and Flex Architecture on Grails

  1. Les Hazlewood

    Hi Thomas!

    Just to let you know – I use JSecurity (not the JSecurity grails plugin) in a Flex application at work seamlessly. Flex communicates via HTTP. After JSecurity sets a cookie (session id or principals or both), flex will send those cookies back to the server with every request automatically – nothing you have to do.

    The JSecurityFilter then intercepts every flex request to ensure Subject information is associated with the incoming request. This is done by mapping the flex remoting url path in the JSecurityFilter’s [urls] configuration section.

    For example:

    [urls]
    /messagebroker/** =

    where /messagebroker/** is the path assigned to the flex remoting servlet and is a filter chain definition you want JSecurity to apply when those requests come in. See the JSecurityFilter JavaDoc for more.

    Best regards,

    Les

    Reply
  2. Les Hazlewood

    Oops, that didn’t show up well. That [urls] example should have shown up like this:

    /messagebroker/** = [filter chain here]

    where [filter chain here] is a filter chain definition you want JSecurity to apply when a request comes in.

    Reply
  3. Tomas Lin Post author

    Thanks Les. I’m not saying it’s not possible, I’m saying it requires a lot of work to get right.

    Let me clarify that, the difference I was talking about is that in a pure Flex application, you are managing all your urls via either the BrowserManager or SWFAddress. This means extra work that needs to be done at both the server and client levels to ensure proper authentication.

    You also run into security issues trying to pass username and password tokens into the server for authentication, requiring you to write your own custom authentication scheme. The point is that using the Authentication plugin or Jsecurity plugin is out of the box with a HTML page based authentication, but less clear with Flex.

    Hope that makes sense.

    Reply
  4. Andy Edmonds

    I too have used JSecurity along with a Grails and Flex based application and like Les found it to be suitable for most cases…. except for one area in which it’s deficient. File uploads like Tomas says are tricky and anaemic in Flex/Flash but they can be done. We did them in our application but what let us down was the lack of support for the Grails security frameworks by the Flash runtime. Perhaps this has now been resolved in F10… not sure

    Reply
  5. Jonathan

    Hi all,

    I’ve been trying to upload files with flex and grails and i had problems. It seems like all of you did it. I want to know how did you did it. I’m stuck in this for months and i’m really thinking about using php at server side to get those files sent from flex.

    I wrote about this in another comment when Thomas published ‘A Simple Grails Controller for File Managment’ post, but nobody answered it.

    Thanks for helping

    Reply
  6. Pingback: 5 Reasons for Flex Developers to consider a Grails / Google App Engine Backend « Tomás Lin’s Programming Brain Dump

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s