Architecture of the Ruboss Application
The Flex Part:
Let’s first take a look at the Flex front end. The main goal of an Enterprise Flex application is to send and receive data to/from a server. Data may be sent in three main formats: XML, JSON, or AMF. XML as a data transfer format is the simplest to understand and most widely used, so that’s what we will use here. JSON is an up and coming format that uses a hash of key:value pairs to transfer data and is thus faster than XML, which can become bulky. AMF is Adobe’s binary data transfer format (Action Message Format) and is by far the fastest to transfer data, but we will save that for later.
So our goal is send XML data from Flex (or Flash, it’s just Actionscript) out to a server so a language such as Ruby, PHP, or Python can act do something with it (access a database, store it on a remote hard drive, etc.); we are using Ruby. Once Ruby does its thing to the data, it sends back data to Flex in any format (and it can be a different format). Flex then displays the changes on the user interface. All of this data transfer occurs RESTfully, that is, occurs over HTTP using only GET, POST, UPDATE, and DELETE.
So what is happening???
Enter Cairngorm. Enter RESTful Cairngorm. When we type text into the Post text input boxes and check the check boxes in the view, and click “Save”, here’s what happens, in a nutshell…
View:
-Text and checkbox data are assigned to the attributes of the Post model. Our Post model has the attributes title, subtitle, body, author, published boolean, and created_at date.
-The button click executes a simple function and passes it a RESTful Event type: sendData(Flexible_blogEvents.CREATE_POST).
-The sendData(eventType) method dispatches a Cairngorm Event (a regular Event with the added data:* parameter that we use to pass in the Post model) of eventType Flexible_blogEvents.CREATE_POST.
Controller:
-A centralized FlexibleBlogEvents class keeps a list of all the RESTful Events in the application. This eliminates the need to have a potentially unlimited number of similar event classes.
-The AppController class is instantiated in the Flexible_blog.mxml main Application MXML file. This allows all events to be listened to and acted upon from the centralized main application file. The AppController executes the appropriate Command based on the Event it receives, and passes the Command the Event along with its data. In our case, the PostCommand would be passed the CairngormEvent of type Flexible_blogEvents.CREATE_POST and executed.
-The PostCommand’s execute() method is called, assigns the event.data value (the Post model and the values it was assigned from the view) to a variable called editedPost of type Post, and calls the corresponding createPost() RESTful method. The createPost() method then does some neat Ruboss magic. Where you would normally have to create a delegate and then do a complicated HTTPService request, Ruboss made it so all you need to do is call the create() method on the editedPost model and pass it a callback function. We do this with the line: editedPost.create({afterCallback: onPostCreate}).
-All of the complicated data transferring over the server to Rails and ultimately to MySQL is handled by some Ruboss magic we don’t have to worry about, but I’ll go a little in a bit anyway.
Model:
-The model extends the RubossModel class, allowing us to call RESTful methods directly from the model. The model is also an Actionscript representation of the database entity, so it has a reference to all of its attributes and its relationships to other entities (belongs_to, has_one, has_many). Our Post model has the attributes title, subtitle, body, author, published, and createdAt.
-I’ve also included a ModelLocator that is instantiated anywhere we want to change the view state of the application (say, from the login screen to the main application).
So now we have a Flex application that follows a RESTful MVC Architecture. Cairngorm was made RESTful by 1) creating a single and centralized Events class that is really just a collection of strings, and 2) creating a single Command for every Model that executes either of four RESTful methods based on the Event type (done by Ruboss magic). Now you hardly have to think about how to connect a Flex UIComponent to a database.
Ruboss’s Flex Magic:
Ruboss effectively eliminates the need to manually use Flex’s HTTPService class to talk to transfer data across a server. It does so through its RubossModelController class. The RubossModelController’s main job is to call the appropriate RESTful methods on a model. So if you send an event type Flexible_blogEvents.CREATE_POST, it will execute the create() method on the Post model in the RubossModelController. each RESTful method has reference to the targetServiceId (HTTP, AMF, etc.), the metadata of the model as it transfers across the server, and a a callback object to handle the server response. All the hard stuff is done for you! Note, only the “index” and “show” methods dispatch a propertyChange event, allowing Flex to update its view.
Another important Ruboss class is the SimpleHTTPController. It has one method called send() that instantiates Flex’s HTTPService, assigns the service an HTTP method, and uses an AsyncToken to send the HTTP request to the server. This is how it is used, for example, in creating a “session” from the SessionsCommand.as file:
public function createSession():void { // the "session" is the url we invoke in rails. new SimpleHTTPController().send("session", {login: session.login, password: session.password}, SimpleHTTPController.POST, this); // "this" is the "responder" }
Because Flex and Actionscript only support two HTTP methods (GET and POST), Ruboss does some magic to add DELETE and UPDATE. Pretty neat! To see an example of how to use the SimpleHTTPController class in a Command, check out how the SessionsCommand was implemented.
Now we have the RubossModel class. This is a bindable class that all models extend (like our Post model) that 1) creates variables for each model attribute you typed into the command line, and 2) allows you to call RESTful methods directly from itself. Again, the “show” method dispatches a propertyChange event to update Flex’s view.
In order to clone a model, use the RubossUtils class: RubossUtils.clone(model). It also has functions to see if the model belongs_to another model, or has_many or has_one of some other model. There’s some great stuff in this class.
Finally, we have the main Ruboss class. The only two things you need to know now about this class are that it has a reference to the ModelsCollection class through the variable “models”, and the “filter()” method. When you call the “create()” method on your Post model (or any other of the RESTful methods), the RubossModel class executes the following:
Ruboss.models.create(editedPost, onPostCreate). Ruboss handles a lot of the repetitive coding was handled for us in the background. You use the filter method if you want to provide different views of the same model. Implement it like this:
Ruboss.filter(Ruboss.models.index(Post), yourFilterFunction);
There is also an AirServiceProvider class, but we will do that sometime later. That’s it for the Ruboss magic! Ruboss takes care of all the HTTPService requests in the background, making it so we can just call the method we want from the model. In addition, the Ruboss Framework is extremely elegant and only consists of 22 classes. Nice.
The Rails Part…
So now we have XML data (or JSON or AMF) that has bend sent from Flex as an HTTP request, and our Rails side of the application needs to handle it. No problem. This works because of Rails “routing” and its MVC architecture.
When we called the editedPost.create() method, an HTTPService request was sent that was packaged with a URL to manipulate our database Post model. It sends off a URL called “posts” along with the method “POST”. The URL “posts” tells you that we are using the posts_controller. When Rails receives this URL request and HTTP method, it executes the “create” method in Ruby.
Here is the “create” method that Ruboss scaffolds for us:
# POST /posts # POST /posts.xml # POST /posts.fxml def create @post = Posts.new(params[:post]) respond_to do |format| if @post.save flash[:notice] = 'Post was successfully created.' format.html { redirect_to(@post) } format.xml { render :xml => @post, :status => :created, :location => @post } format.fxml { render :xml => @post } else format.html { render :action => "new" } format.xml { render :xml => @post.errors, :status => :unprocessable_entity } format.fxml { render :xml => @post.errors } end end end
Every Ruby on Rails controller class looks the same, thanks to the excellent design patterns and scaffolding. First we create a new post, then the respond_to do block saves the Post and renders the result as either HTML or XML. I’m guessing the FXML format is “Flex XML” and basically reformats the XML to get rid of dashes and subtle formatting differences between Flex and Ruby on Rails. All of that is happening in the background. To see how it actually works, go to the file in the vendor/Plugins/ruboss_rails_integration/lib directory called ruboss_rails_integration.rb. This is where they register the FXML mimetype and do all the conversions and such.
Here’s what happens in Ruby on Rails in a nutshell…
View
- Ruboss doesn’t use Rails’ ActionView templates because of Flex. So our View is Flex, and it sends its data as XML (or JSON or AMF).
Controller
-URL from the Flex HTTPService request is routed to the appropriate controller (posts_controller in this case) via the routes.rb file.
-The appropriate controller method is executed (”create” in this case). This access and manipulates the database object using, for instance, Post.find(:id) for “show” or Post.new(params[:post]) for “create”.
-The resulting data is returned to the controller and then formatted to XML or any other specified format. This is then read by Flex.
Model
-In its most basic form, the model has just references to the objects it associates with (belongs_to, has_one, has_many). Can have other methods if you want to organize the data a certain way.
-A Migration file is created (create_posts) that allows for easy integration of the model into the database.
That’s it for now.
ToDo’s:
- Create a scale-proof Ruby on Rails server cluster to embed into Ruboss (Heroku?)
- Create Flex MXML templates for a Blog, Comments, Search (with Sphinx) Forum, Profile, Wiki, PhotoGallery, and Podcast Viewer.
If you enjoyed this post, make sure you subscribe to my RSS feed!