The JumpShip Rails Gateway is a simple way to get to connect a JumpShip application to a Ruby on Rails back-end. The Gateway uses REST and the standard XML structure Rails generates to perform Create, Read, Update, Delete (CRUD) operations between the Flash front-end and the Rails back-end. The Gateway handles the translation of the data to and from the JumpShip Data Model, JSDataModel.

The JumpShip Framework embraces one of the fundamental principals of Ruby on Rails, Convention over Configuration. This is why JumpShip and Rails are a natural fit. There are many ways for Flash to communicate with server-side applications, even for Ruby on Rails. The most popular of these is Flash Remoting which provides developers the benefit of being able to send virtually any data type back and fourth and have them translated on both ends into native Flash and Ruby, PHP, Java object. But the amount of flexibility that Flash Remoting ( or other communication solutions ) provides comes at the cost of simplicity and forces you to spend valuable brain cycles deciding how to set up your application and define your data structures.

If you are using JumpShip, you have most likely already adopted a standard Data Model on the Flash side ( the JSDataModel ). And once you decide to use this standard Data Model, all of a sudden life gets a whole lot simpler. There is really no need to invest in the overhead of Flash Remoting if you already know that every piece of data is ultimately going to be put into a standard Data Model.

The goal of the JumpShip Rails Gateway is provide a standard, easy way to get your JumpShip application up and running with a Ruby on Rails back end. Here’s how it works.

The JumpShip Rails Gateway ( JSRailsGatewayBase ) leverages the Ruby on Rails adoption of RESTful development to interact directly with Rails data models. The Gateway performs the basic task of translating a JumpShip Data Model ( JSDataModel ) into RESTful calls to perform basic CRUD operations.

The basic Ruby on Rails Data Model ( ActiveRecord ) is an abstraction of a database table. The JumpShip Data Model was designed to look and work very similarly to ActiveRecord. While the JumpShip Rails Gateway comes built in with basic CRUD operations, the Class can be extended to provide other operations specific to your application.

In order to initiate an interaction between Flash and the Rails server, you first crate an instance of JSRailsGateway and associate it directly with a JSDataModel. You then make sure the JSDataMode.modelName is the same as the Rails Model it will talk to on the server. You use the methods JSRailsGatewayBase.dataSubmit(), JSRailsGatewayBase.dataUpdate(), JSRailsGatewayBase.dataRequest(), and JSRailsGatewayBase.dataDelete() to perform your C,R,U, and D respectively.

dataSubmit({record:JSDataRecord});
dataUpdate{record:JSDataRecord});
dataRequest({method:"list || show", id:String});
dataDelete({record:JSDataRecord});

dataSubmit is for creating a new record in the database. dataRequest is for retrieving data from the database and putting it into a JSDataModel object. dataUpdate is for updating a record in the database with new information. dataDelete is for deleting a record in the database.

The parameters that should be passed along with these messages are the following.

The parameters for the “dataSubmit” message look like {record:JSDataRecord}. The “record” is the JSDataRecord that contains the data record to be added to the database.

The parameters for the “dataRequest” message look like {method:”list || show”, id:String}. The “method” parameter determines weather to show all records “list” or just one record “show”. The second parameter “id” is used with the “show” method to determine which record to show.

The parameters for the “dataUpdate” message are the same as “dataSubmit” and look like {record:JSDataRecord}. In this case the id of the JSDataRecord will be used to select the record to update.

The parameters for the “dataDelete” message are the same as “dataUpdate” and “dataSubmit” and look like {record:JSDataRecord}. In this case the id of the JSDataRecord will be used to select the record to delete.

After sending one of these messages to the Rails server, it may receive a reply containing data or a message (messages can be received if enableMessaging is set to true. Otherwise a message returned from the server will be considered data). The JSRailsGatewayBase issues two events based on the type of reply it receives for the server, RailsGatewayEvent.MESSAGE_RECIEVED or RailsGatewayEvent.DATA_RECIEVED.

In the case of a railsMessageReceivedEvent, the event will also contain an object with parameters that may be passed back from the server. The most cases, the RailsGatewayEvent.MESSAGE_RECIEVED will contain an object with the type of message being sent back and a success flag that indicates whether the operation succeeded or failed: {type:String, success:Boolean}.

In the case of a RailsGatewayEvent.DATA_RECIEVED, the event will contain a JSDataModel object with the data that was returned from the Rails server.

It is beyond the scope of this documentation to go into the basics of Rails or the Ruby language, but on a broad level, scaffolding that is built into the latest version of Rails produces RESTful ways to interact with data models.

The JSRailsGateway takes advantage of this feature in order to interact with the Rails models on the server.