Combining Flex and Scala using Liftweb and BlazeDS

2009-01-18 17:05:03 +0000

I wanted to setup a sample project that uses Flex and Scala. I followed the excellent tutorial on FlexOnRails: Integrating Flex, BlazeDS, and Scala/Lift. The tutorial helps a lot explaining how to set up your sample project. Unfortunately the tutorial is a bit outdated with regard to latest versions. Fortunately I could solve all problems! I'll list the problems I had. Also, I'll post my project. I won't redo the tutorial, as I certainly couldn't to a better job then Derek Wischusen.

  • First problem I had, was getting my backend compiled. The liftweb has changed slightly, as a result the class Boot.scala didn't work anymore. I could solve it by downloading the latest Liftweb framework, version 0.9. I copied & pasted the Boot.scala from the sites/examples dir. After a few tweaks (removing code I didn't need), the project compiled successfully!
  • Then I wanted to setup the flex project. That was quite easy, using the latest version of Flexbuilder (version
    I setup flexbuilder to deploy in the backend/webapp directly, as is explained in the tutorial.
  • I ran the project by running the following maven commands in the backend subdir:
    mvn package
    mvn jetty:run
  • While running the example, I got a AbstractMethodError. I wasn't the first person to get that error, as I found on the Liftmailinglist. I could fix the problem by using Scala version 2.7.1 for my own project. All in all, when using bleeding-edge technologies, having the latest version isn't good always!
  • After that I ran the project  again. Now I get a NullPointerException, seems the line val msgBroker = MessageBroker.getMessageBroker(null) returns Null.
    Turned out I forgot to update the web.xml, the Flex servlet and other configuration has to be added.

I named the sample project Elegante. Download the source here: For explanation see the original tutorial.

Read more

Pattern in RIA

2009-01-17 16:49:48 +0000

The Flex framework is getting more and  more populair, and other similar RIA-frameworks as JavaFX and Sliverlight get a lot of attention. Some people see Flex as a alternative for webframeworks as Widget, JSF, Struts or GWT. However, there's something fundementelly different. When program in Flex, you actually build a client-application. That application runs entirely on the client's computers. The client connects to the server only when the client need information from the server. The client retrieves information via (web)services.

The pattern (as you can call it) is very unlike webframeworks, where the software runs mostly on the server. When a user accesses a webapplication, the webframework will generate html, javascript and xml and send that to the client's webbrowser. The webframework also needs to create a (HTTP-)session along with a sessionid that is stored at the client-computer.
When a client performs some interaction, like pressing a button, a relatively complicated process is started: a javascript event or browser submit is emitted. The webframework will retrieve that event on the server using generated javascript- and html-code. Using the sessionid, the right user-session, containing client-data is loaded after which more automagic processes are performed.
You might wonder, what about Ajax ? The answer, with Ajax, or JQuery or other framework, the only advantage is, in case o a UI-event not the entire browserpage has to be reloaded and shown on the user, but only a part.

Not so long ago most enterprise software was developed as client-server: a client application would run on an users computer, while the server would consist of a database server. The client would make a connection to the database. The (business) logic of the software was contained in the application, while the database contained the data.
This development-model was quite easy for developers. I don't have hard data, but I think the productivy was much higher back then. My guess is that, for many simple CRUD-like requirements, a average Visual Basic, Delphy, Clipper developer was a lot faster.
Of course one of the mayor problems back then, were the installation and maintance of the client computers. Webapplications pretty much solved that, as the only client software you had was the browser.  Another problem is security: usually the client was connected with the server via a direct connection to the database. That means, if an unauthorized user would gain access to the client software he could do a lot of harm.
In webapplications, a user can only access the software by logging in the the webapplication. Without a username/passsword or other means of authentication, getting access to the server is very hard.

In modern RIA frameworks these problems are mostly solved. The software runs in a standardized plugin like the flash-player or java-player. That software is a lot easier to maintain then custom client software. A RIA-application accesses the server via a webservice. Fine-grained security can  added accessed to the webservice, preventing unauthorized access. That way, access to the server/backend can be controlled.

All in all, modern RIA bring back productivity to the developer and the user. Developers finally don't have to waste time learning yet another greatest framework (Struts, SpringMVC, JSF, ADF, GWT), and solving problems inherently part of webdevelopment (http-sessions, javascript debugging, html hell, generated code) . Users finally don't have to wast time waiting for browser refreshes, loading times and timewasting slow operations.

For an overview on different RIA-frameworks, and more on this subject see: Rich Internet Applications: State of the Union . The term design pattern for RIA I got from the following presentation of a Adobe Evangelist on J-Fall '08.

Read more


subscribe via RSS