[ Please send comments to tomaslin@gmail.com - please be ruthless ]

In this book, I am going to try to marry the processes and technologies of rapid application development to the creation of Rich Internet Applications (RIAs). This chapter introduces RIAs and explains how full stack frameworks like Grails provide the process and technologies to supercharge their development. Let's start by understading a little more about RIAs and the development process. While the focus of this section has examples that target Flex and Grails, a lot of these principles are transferrable to similar technologies like DWR, GWT, OpenLaszlo, Capuccino, Silverlight, Django and Ruby on Rails.

What are Rich Internet Applications?

A big part of this book is about building Rich Internet Applications. The term was first used by Macromedia in 2002 (http://download.macromedia.com/pub/flash/whitepapers/richclient.pdf), but the idea has been around for much longer. Also known as Rich Clients, Web Clients or Web Applications, RIAs are cross-platform applications that bring a lot of the usability and functionality typically associated with desktop programs to the web. The term RIA has been used to define many different types of technologies. You can have RIAs written in JavaScript, Silverlight, Flex or any other framework. For this book, we will refer to RIAs not as a combination of any specific technologies, but rather to the notion of web and desktop apps that interact with media and data in a rich, intuitive way.

It's probably easier to understand this difference with an example. Let's compare the difference in user interface experience between a Rich Internet Application (RIA) and a traditional web application. Take a look at the eBay website ( http://www.ebay.com ), and it's RIA equivalent, the eBay Desktop Client. ( http://desktop.ebay.com/install.html )

Now, both applications allow you to browse products and bid on auctions, but you might notice that the desktop client is slightly easier to use than the website. Here are some of the features of Rich Internet Applications compared to traditional websites:

1. Highly Interactive and Dynamic User Interfaces.
   
   Compare the way eBay Desktop presents category filters on top of the page with the traditional HTML page. You will note that whenever you click on a particular filter, only the content of the page reloads. In the website version, the entire screen refreshes. RIAs are built so that the entire user interface is responsive and major parts of the website can change without having to reload. This only scratches the surface of the highly responsive UIs that can be built with RIAs.
   
   Sites like Aviary and Photoshop Express both provide complete image editing tools that are built on RIA technologies. The Mini-Cooper website uses Flex to enable users to customize a car in the same way that you might in a racing video game.
   
   RIAs have features that are normally not associated with static pages built with HTML. Drag and Drop, animation, dynamic charting and inline data filtering are some of the things that are easy to pull off in RIAs, but much more difficult in a traditional website.
   
   
2. Rich Interaction with Embedded Media.
   
   Flash is the king of web video. According to ComScore, 81 percent of the video streamed on the Internet is done via Flash ( http://www.adobe.com/aboutadobe/pressroom/pressreleases/200811/111708AdobeFMS35.html ).  RIA platforms like Flex and Silverlight have been embraced because they make adding and interacting with audio and video much easier on the web. Traditionally, to add a video or audio, you would have had to include a plugin like the RealPlayer or Flash. But because Flex RIAs compile into the Flash platform itself, there is no need for additional external dependencies for audio and video playback.
   
   As a result, RIAs are able to interact more effectively with rich media. The Ebay Desktop, for example, uses a short little video at the beginning to show users how to use their services. Other sites have taken this integration further. GrooveShark uses the ability to embed audio to provide an amazing interface for sharing and finding music online. Parleys not only embeds videos of presentations and talks with Flex, they also sync up presentation slides with the video.
   
   
3. Desktop / Browser boundary is blurred.
   
   With the introduction of desktop runtimes like Adobe AIR, developers can build applications that are installed like desktop applications and yet are built and communicate with websites in the same way their web counterparts do. Unlike platforms like Java Swing or Visual Basic, the same components used for web development can be deployed and used on the desktop.
   
   Ebay Desktop is certainly a perfect example of bringing the web to the desktop. There are also twitter clients like Tweetdeck and Twhirl, Google Analytics Clients like Desktop Reporting and even stock information tools like the NASDAQ Market Replay. In fact, Adobe has a marketplace for RIAs built to run on the desktop.
   
   
4. Component Driven Development.
   
   RIA frameworks like Flex and Silverlight emphasize development using components. Components are re-usable pieces of code that most often provide an user interface and interact with other components via an event model. On Ebay Desktop, for example, we see extensive use of tabs, and the search results are displayed in Adobe's Datagrid component, which allows for dynamic loading and reloading of data.
   
   Compared to traditional HTML elements, Flex ships with user interface components like tabs, accordions and data tables designed specifically for displaying data and easing navigation. Sure, you can add this functionality easily to HTML pages with modern JavaScript widgets like Dijit, YUI and JQuery plugins. The main difference is that RIA frameworks like Flex makes them a core part of it's framework, rather than an add-on. It is impossible to add a tag in HTML called <accordion>, but with Flex, using the <mx:Accordion> markup is perfectly valid.
   
   This component-driven model encourages code re-use. In Flex, you can even re-use commercially available Flash components like the 3DWall and those available on Flashden.com. Flex.org maintains a list of reusable Flex components.
   
   
5. Robust Data Support.
   
   Since RIA applications are not as closely bound to the server in the ways HTML pages are, RIAs are capable of handling and merging data from multiple sources on the client side. HTML pages are generated on the server side, so if you want to access any third party systems, you would have to do all this procession on the server and render the right information back. The data transfer formats are limited to what is returned by the server. RIAs, on the other hand, are not closely bound to the server and are capable of retrieving data from multiple sources and in multiple protocols.
   
   Ebay Desktop provides a simple example by connecting to the eBay data API and retrieving information on demand based on query or filter parameters.
   
   A single RIA is capable of retriving data from multiple sources and servers. Tweetdeck, for example, allows users to post status updates to both Twitter and Facebook. RIA clients are excellent integration hubs for . Airtalkr is a chat client built with Adobe Air that connects to the APIs provided by different Instant Messaging platforms and presents all this information in an unified interface. The Tour De Flex, Adobe's showcase of Flex components and APIs, provides detailed examples of different services and how to connect them with Flex.
   
   RIAs are also capable of supporting data transfer formats and messaging protocols that are usually not found in traditional HTTP servers. Morgan Stanley's Matrix application, for example, uses the RTMP protocol available in Flex to provide peer-to-peer chat, video streaming and real-time online stock quote information. We will discuss these options in depth on the Server-side Flex chapter.
   

RIAs are exciting because they provide an alternative to traditional website development. The technology is designed to allow you to build applications, not pages. HTML and AJAX is excellent for presenting data that is heavily text and form-based. But HTML/AJAX breaks down when you try to present information that requires more elaborate use of graphics or want to include richer interactions. RIA frameworks, on the other hand, were built from the ground up to support visually appealing and highly interactive applications.

If you want to learn more about Rich Internet Applications, Adobe has put together a very informative section on their website for both techies and business decision makers. ( http://www.adobe.com/resources/business/rich_internet_apps/  ). I also encourage you to check out the book Pro Spring on Flex by Chris Giametta, which provides a much more in-depth discussion of the architectural differences between RIAs and traditional web applications.

Rapid Development with Grails 

Writing RIAs backed by a server is a complex process. There are components that need to be built on both the client and the server, and their development must be coordinated and synchronized. Fortunately, there are tools and processes that can help coordinate this endeavor and make development manageable. One of the most exciting recent developments has been the emergence of full stack frameworks like Grails which aim to simplify the development process. This section will discuss some of the characteristics and goals of these development frameworks.

A common misconception about Grails is that it is nothing more than  just a CRUD framework, i.e, it provides services only to automatically create screens to manage data in the database. While the generation of CRUD screens is a powerful feature in Grails, it is only a very small part of the entire framework. Hopefully, this section will explain the type of development that is possible with a rapid application framework like Grails.
 
One of the main goal of Grails is to keep Java development simple and manageable. It promotes a project structure and development processes that encourages code re-use and attempts to reduce needless complexity associated with working with Java. By eliminating a lot of repetition and overhead from traditional development, Grails enables us to build web applications rapidly.

Grails takes two important ideas normally associated with Ruby on Rails in it's implementation and design philosophy:

1. Convention over Configuration. Provide a sensible, default way of doing things. 
   
   In Grails, you don't spend a lot of time setting up XMLs or tweaking and fine-tuning code defaults. Instead, there are sensible defaults provided technologies that are integrated into the framework. This allows developers to get coding right away. Traditionally, Java developers would have to spend a lot of time configuring XML files and binding libraries to each other. With Grails, a lot of this is handled by the framework, allowing you to get to work right away. To install the BlazeDS integration, set up hot compilation and enable channels, for example, one needs to only call grails install-plugins Flex, which does all the above configuration automatically for you.
   
   But the idea of Convention over Configuration goes beyong just code. The framework provides a convention for a project structure, build process and a way to set up configuration settings after deployment. This enables programmers to work faster, as they don't have to re-invent the wheel for each project.
   
   
2. Don't Repeat Yourself ( DRY ). Put things in one place.
   
   This might seem like a simple idea, but it seems contrary to the beliefs of traditional Enterprise Java developers. If you pick up a book on Flex on Java, you would notice that each chapter teaches how to rewrite the ideas of the last one with a different technology. Each book will trace a familiar SQL -> Hibernate -> POJO -> DTO -> ActionScript -> Front-end path.
   
   Grails development, on the other hand, picks one spot where your application defines it's main characteristics and uses a combination of code templates and script generation to take care of the rest. In Grails, for example, you would describe your model in a series of domain classes and then use the generate-all to build everything down to the database level and everything up to the UI. Whenever you need to change a functionality, you simply modify and change the scripts.
   

Here are a few other things that you might not have realized about Grails,

1. It's Not Just a Web Framework, It's a Full Stack.
   
   Instead of just providing a technology to build user interfaces like SpringMVC or a web layer like Struts, Grails contains all the pieces needed to develop web applications. It has an embedded database (HSQL), a web server ( Jetty ), a web framework ( Spring ) and a UI templating engine ( Sitemesh ). This makes setting up and writing code much faster for developers who don't need to worry about the hasle and complications associated with setting up traditional J2EE engines. Moreover, through it's robust plugin mechanism, Grails allows for pieces to be swapped out. You could use the gorm-JPA plugin to replace Hibernate, for example, or the Tomcat plugin instead of Jetty.
   
   
2. End-to-End Development Process.
   
   The Grails framework helps deal with the entire development process. There is an application template for creating new applications, scripts to help generate domain objects, controllers and views during development, hooks to help build, a built-in unit and integration test framework, and facilities to get the application ready for deployment. Grails helps handle and simplify the application lifecycle and provides the same convention over configuration principles to this process.
   
   
3. Encourage Coding Best Practices.
   
   The Grails application template separates code based on the popular Model-View-Controller pattern. It puts all the data into domain classes, all the user interface screens into views and all the business logic that ties it together in controllers. This is extremely helpful when you're working with multiple groups of people within the same project that might have different skill sets and levels of programming expertise.  For our projects, we could assign views and css to front-end developers without worrying about how they would accidently change backend or database logic. The MVC pattern allows this simple separation of concerns and makes development smoother.
   
   Grails also has test-driven development embedded in it's DNA. When you create a domain object, an unit and integration test are automatically generated. You can also add functional tests and code coverage tests via plugins. There is even a plugin called CodeNarc that will try to rat out bad code practices. By making testing easy and an integral part of the framework, Grails promotes the ability to build that minimal safety-net of code checkins needed for bullet-proof development.
   
   
4. Extensible and Flexible.
   
   Development with Grails is not a closed system. Rather, the framework has a robust and extensible plugin architecture that allows developers to add new libraries and functionality using the same convention over configuration approach previously discussed. There have been many plugins written that provide anything from security, search, pdf generation and even business rules engines. You can take a look at the list of avalable Grails plugins at http://www.grails.org/plugins.
   
   Under the hood, Grails is powered by a dynamic language based on Java called Groovy. Groovy allows many features not available via traditional Java. One of these features is a powerful MetaClass system that allows methods and properties to be injected into Groovy classes on runtime. This makes Grails highly-extensible and creates very powerful combinations. For example, GORM, the interface between Grails Domain Objects and the Database, uses this ability to create dynamic finders - methods that combine properties of domain classes such as findAllByBookAndAuthor() on the fly.
   
   
5. Ease of Development.
   
   With all these features, it might seem that usability goes right out the window. However, compared to other frameworks that rely heavily on XML, Grails stays away from needless complexity. The Convention over configuration philosophy permeates the entire stack. For example, instead of XML, Grails promotes the use of Groovy syntax and DSLs, which looks more like JSON. Moreover, plugin developers work hard to hide insidious implementation and deployment details of some libraries by providing shortcuts to integration. Making a domain object searchable in Compass, for example, would simply involve adding the searchable = true property. The plugin then generates all the magic that configures this domain into Lucene and makes it available.
   
   The Groovy language also eliminates much of the verboseness of Java. By leveraging many of the features of scripting languages, Groovy allows developers to write less code. No longer are imports or getters and setters needed in classes. Powerful features like closures, duck-typing and XML-processing are built right into the language. This results in code that is still compiled into Java bytecode but has less code noise.
   
   Due to the popularity of Grails, there are also many more open-source and commercial IDEs to help developers. IntelliJ Idea, Netbeans, Eclipse and TextMate all offer Grails support. Debugging and profiling Grails applications have never been easier, and tool support just keeps getting better and better.
   
   
6. Still Java.
   
   Scrape away all the nice scaffolding and helpers, and you will see our good friend Java at the bottom of Grails. Grails is built on proven enterprise technologies such as Spring and Hibernate, and integrates via plugins with other well known libraries such as Lucene and Drools. One of the advantages of this Java driven development is that it virtually guarantees compatible APIs in third-party integration. Facebook Connect, Paypal and most third party payment gateways have a Java API that can be integrated using Grails. We will see in the next section how this Java heritage actually makes integrating Flex and Grails simpler and seamless.
   

Overall, Grails provides a way of building applications that speed up the traditional J2EE development process. By providing a sensible default way of doing things, Grails takes away a lot of the guesswork associated with traditional development. Instead of forcing developers to configure external libraries and repeat code over in many places, the Framework provides an application skeleton that takes care of a lot of these problems. It helps developers focus on the core functionality of their application, rather than sweating a lot of the little details and repetition.

The power and productivity from frameworks like Grails can really only be appreciated if you see it in action. If you haven't seen this and have an hour to spare, I strongly encourage you to check out the Build Twitter in 40 minutes webinar, hosted by Graeme Rocher, the project leader for Grails.

We will discuss the features specific to Grails later on. If you want alternative view of the big ideas within the framework, you should also check out the excellent Green Paper published as part of the promotion for the must-have Grails in Action book.

Building Flex RIAs with Grails.

The challenge of this book is to integrate the Rapid Application Development process used to build traditional web applications available to a framework like Grails and apply it to the development of the component-driven, service-oriented model encouraged by the Flex Framework. Can Grails be used to help in the development of RIAs?

To understand how we can modify the Grails development process, let's first look at the differences between an RIA and a HTML-based application. In the following diagram, the red arrows represent a typical way in which data flows across an application.

In a traditional web application, a web request comes in and is processed by the controller. The controller first pulls the data it needs and passes it to the views. The views pull in additional information it needs for display from layout templates ( Sitemesh ) and reusable bits of code embedded in tags. It then uses this data to generate a HTML file, all within one request. ( Note: this is a slight simplification to what actually happens, controllers in Grails can also output to web services and other formats. )

Many of the ideas in this book evolved from my discussions with colleagues Jakob Külzer and Tim Spurway regarding proper application development and design while trying to meet hectic accelerated deadlines associated with design agencies. We were able to apply early ideas on Flex and Grails development to several of these agency projects and prove that they were in fact viable. The following section showcases some of the work we've done:

• Blueembergrills.com - One of the first commercial projects I did on Flex and Grails. Flex enabled us to build highly visual interactions such as a 360 degree view for grills and embedding information movies for the site. Grails allowed us to quickly enter data needed for things like grill comparison, recipes and parts catalogues. To the team working on this, it definitively proved that Grails was a viable solution to building these type of interactive websites.
  
  
• Suzuki.ca - One of the largest and most involved projects we did with Grails and Flex. Flex was used to provide image galleries, car configuration and payment calculation features to the site. Due to the sheer amount of data needed to be fed into the site, Grails and it's ability to define custom object models allowed us to quickly build a content manager to support the data to be presented on the site.
  

• Dan Aykroyd Wines - Flex is used in this site to display tutorial videos, product browsing and provide a custom wine tour of the world experience. This site showcases an architecture where traditional HTML pages were combined with Flex elements to improve SEO. Text heavy areas like newsletters, blogs and press releases were kept in HTML. Highly graphical and dynamic areas like the wine tutorials were done in Flex.
  
  
• Tacobell.ca - A project lead by Jakob Külzer. This site uses Flex to provide dynamic filtering for an online menu, a Google Maps-aided branch location search and embedding of a Flash-based game ( Burrito Blaster ).
  

A Brief Timeline for Flex and Grails.

Of course, the ideas and processes presented in this book would not be possible without the hard work of the open source community and tools created by Adobe and SpringSource. We are at a very exciting time when it comes to Grails and Flex development. Adobe has started to push Flex as an enterprise tool to help increase usability and interactivity within organizations. More and more tools have also come in the Java and Grails world to aid in this development. It's hard to imagine that just three years ago, many of the tools and ideas discussed in this book did not exist.

The following section provides a brief timeline of interesting tools, products and events that make the work described here possible:


Upcoming -

• Flex 4 is scheduled for released at the end of Q1, 2010.
• Updated Flex-Grails plugin, as outlined in the Grails roadmap.
• Grails 1.2 is released.

Summary

This chapter introduces the idea that we can use the rapid application development process available to full stack frameworks like Grails to make building the server and client side components of RIAs much simpler.

[ Edit Notes : More pictures to break monotony of text ]