Jumpship, version 3.1, the most recent addition to open-source Flex and ActionScript rich Internet applications (RIA) was released on May 21, 2008. As part of our efforts to stay abreast of RIA development frameworks, InfoQ spoke with Jamie Scanlon, the creator of JumpShip Framework. Scanlon, who is also the owner of the Web design house, JSJ Studios, says he was inspired to develop JumpShip owing to usability issues commonly faced by developers. He recalls:
The framework that became JumpShip started as a solo effort. This idea for it actually came to me after I had completed a particularly large project and had a chance to sit back and take stock of the final product. The project had been built using MVC (a rapid rich Internet application builder for service-oriented architectures). Although it all worked, the code was just way too complex for me. I had controllers and views that were several hundred lines of code. When I was debugging, it was taking me just as long to find the offending code as to fix it. I knew a similar sized project was just on the horizon, and I really wanted to find a better way.
At that time, I discovered Ruby on Rails. It was all the things that I wanted in a framework, particularly in terms of being concise. Although it was based on solid theory, it focused on actually getting things done, rather than lofty GoF design pattern elegance. I wanted that for ActionScript, so I set out to build it.
Scanlon explains:
The goal of JumpShip is to take into account MVC best practices, but in a way that focuses on getting work done. JumpShip is not afraid to sacrifice theory for practicality. JumpShip also tries to adhere to the Ruby on Rails philosophy of convention over configuration. It takes the approach that it's not a bad thing for a framework to take opinions about the best way to get things done when there is no clear, best practices solution. Having conventions means you spend less time worrying about best practices and more time coding.
As to what makes JumpShip different from other AS3 frameworks, like ARP, Cairngorm or PureMVC, Scanlon says:
One of the most unique things about JumpShip is the inclusion of a standard data model that gives you search, sort, data traversal and enumeration automatically. Based on the work done in the prototype community, the JumpShip data model provides an incredibly powerful data structure that works throughout the entire framework.
Another core difference between JumpShip and other MVC frameworks is its conscious effort not to rely on the Singleton pattern as an easy way to create references to other classes.
He recalls:
I had an experience I wrote about recently. I had built a video player in Cairngorm and wanted to port it to another application that required multiple instances of the player to be on stage at once. I ran into a problem when I realized that, since I was using Singleton ModelLocator and Caingorm EventDispatcher classes, any time I clicked the play button on one instance of the player, all of them would hear the event and start playing.
It is my true belief that Singleton patterns have been used with far too little thought in most frameworks. They easily solve the problem of not having to store references to every class. This makes them very convenient, but they can come back to bite you if you are truly building for a widgetized, componentized environment.
Another feature that differentiates JumpShip from others is its use of the Rails Gateway, which provides a library by taking advantage of Rails' adoption of RESTful Web services and provides the ability to do basic Create-Read-Update-Delete (CRUD) operations with a Rails backend. With respect to the integration of JumpShip and Ruby on Rails, Scanlon explains:
Ruby on Rails was my model of how easy a framework could be and how frameworks should make development easier. Based on my experience with Ruby on Rails, I always thought that having a data model that was defined in the framework was incredibly valuable. Rails has an ActiveRecord class, which is an abstraction of a database table and lets you do basic CRUD as well as search, sort and data traversal. When you start to think of your data as an abstraction of a database table, you would expect these types of basic operations to be available. I wanted to make an assumption that the data in my application was just values from a table. I wanted my data model to know how to search, sort, traverse and modify that data.
I also wanted one data model that worked everywhere. I didn't want to have to define value objects for every application, knowing that they could never be used again. The concept of one data model that you can use everywhere, not just for your current project, is still is a new idea in the ActionScript world. It not only saves you development time, but it also forces you, as a developer, to think of a data model as something that should serve you and your application. It is not just a way to parse and store whatever the server gives you. Too often developers fall into the trap of structuring their data models the same way as the raw data they receive, whether that is XML, JSON, or raw objects. Most likely the data coming in is structured in a way that makes sense to the backend business logic. However, as front-end developers, we have no obligation to keep the same structure we are given. We can and should make data work for us, rather than the other way around.
Scanlon also commented on the Rails Gateway, remembering:
At the time that I was developing JumpShip I was working with a rails backend, and there were very few resources for learning how to make Rails and ActionScript talk to each other. I went though a small period of frustration, trying to get my implementation to work. But, in the end, it really wasn't that hard, and I just wanted to show how it could be done. I wanted Rails developers to see how their applications could work with a Flash front end, and I wanted Flash/Flex developers to not be so focused on Flash remoting and AMF, but embrace the larger world of Web services.
As it turned out, I wasn't the only one heading down this path. A few months later, Adobe published an article on using Flex and Rails together. Nevertheless, I continued improving the JumpShip Rails gateway, because I thought there was value in creating a solution that would enable Rails and ActionScript to work together that wasn't Flex specific and that took advantage of the work I was doing with the JumpShip data model.
I realized that another advantage of having a defined data model was that you could communicate with Rails through RESTful services and XML and convert all of the data into the standard JumpShip data model. So you can create a data model called 'users' and tell the JumpShip Rails Gateway to query the server. The gateway would know to query the users table and would know how to translate the XML result into a JumpShip data model. This is really cool! You can also take a JumpShip data model and tell the gateway to save it. The gateway knows how to translate the data model into XML and tell Rails to save it to the database.
Although the Rails gateway is useful for a certain group of ActionScript developers, I have gotten a surprising amount of positive feedback from Rails developers looking to use Flash as a front end who found it very helpful.
InfoQ asked Scanlon to name the top three improvements he'd like to see in the JumpShip framework. He responded:
I would put creating documentation up there as a priority. It’s something I'm currently working on improving. Good documentation is incredibly important to help people understand the power of the framework. However, it is very time consuming, and something that I am not in the best habit of doing.
I would also like to improve community around the framework. I'm hoping that as the community expands and more people contribute their thoughts and experiences, the framework will grow and improve with it.
Finally, I would like to expand the ways JumpShip can be used inside of the Flex framework. JumpShip started as a Flash framework, so I want it to remain useful for developers working with Flash, but I also want it to appeal to the growing number of Flex developers. Although the framework works just as well in both environments, the average Flex developer may find some of the concepts foreign. My goal is to lower the barrier of entry for Flex developers so that they can use JumpShip as easily as Flex-specific frameworks, like Cairngorm.
Scanlon points out that JumpShip is also a good fit for building portable and reusable code, like widgets and components, because it is less reliant on Singleton patterns and less likely to cause conflicts. Overall, Scanlon sees JumpShip as a framework for any developer looking for a practical framework that will enable him or her to get things done quickly without worrying too much about design pattern theory or the best way to implement MVC.