flexonrails.net

In Part 2 of the tutorials that I have been writing about the Issue Tracker sample app (view, source) I discussed how you can Get Typed Objects from Rails using [RemoteClass]. Now, with the latest version of WebORB, it is also possible send typed objects from Flex to Rails.

This means that you no longer have to use untyped objects or XML to send values from Flex to Rails. Now you can just pass typed value objects back and forth between Flex and Rails.

So now, in the Issue Tracker sample app, when an IssueVO is sent from Flex to Rails, because it is mapped to the Issue ActiveRecord class (using the process that is explained in Part 2), it automatically gets converted to an Issue ActiveRecord instance. If the value of the id attribute on the IssueVO matches an existing Issue ActiveRecord then WebORB will return that object, otherwise it will create a new ActiveRecord instance.

This makes it possible to simplify the updateIssue method as follows:

  def updateIssue(issue)
    issue.save
  end

Rails 1.21 was released on Friday of last week. This release has many new features and fixes, including enhanced REST support and enhanced Unicode support. You can read all about it here. Or, if you want to dive right into the details, you check out the CHANGELOGS from the Rails API.

This is the fourth post in a series that covers certain features of Issue Tracker sample app (view, source) that I added to the Flex RoR SDK.

The first post explained how to set up the application.

The second post covered how you can get WebORB for Rails to return typed objects to Flex using the [RemoteClass] metadata tag.

The third post covered how to use ActiveRecord Associations with WebORB.

This post explains how you can invoke ActiveRecord methods directly inside of a Flex client.

WebORB gives you the ability call ActiveRecord methods from inside of Flex. Here is all you have to do to make this happen:

1. To do this you first set up a RemoteObject in Flex just like you would for any other service. For example, the following code is from the Services.mxml file in flex_issue_tracker2 project:

<mx:RemoteObject id="userService" destination="userServiceImpl"
		    showBusyCursor="true
                       result="event.token.resultHandler( event );"
		    fault="event.token.faultHandler( event );">
</mx:RemoteObject>

2. Open up the remoting-config.xml file (located in C:\rails\rails_issue_tracker2\config\WEB-INF\flex) and map the RemoteObject directly to an ActiveRecord class. This is the mapping for the userService RemoteObject:

    <destination id="userServiceImpl">
        <properties>
            <source>User</source>
        </properties>
    </destination>

Now when you make a method call on the userService RemoteObject it as though you are making the call directly on the User ActiveRecord class. This makes it possible to do some interesting things, such as calling ActiveRecord dynamic finder methods directly on the userService, which is what is currently happening in the UserDelegate class in Flex:

package com.rxr.issuetracker.business
{
import mx.rpc.IResponder;
import com.adobe.cairngorm.business.ServiceLocator;

public class UserDelegate
{
	private var responder : IResponder;
	private var service : Object;

	public function UserDelegate(responder : IResponder)
	{
	      this.service = ServiceLocator.getInstance().getService( "userService" );
	      this.responder = responder;
	}

	public function loginUser(username : String, password : String) : void
	{
	      var call : Object = service.find_by_username_and_password(username, password);
	      call.resultHandler = responder.result;
	      call.faultHandler = responder.fault;
	}

	public function registerUser(username : String, password : String) : void
	{
	      var call : Object = service.find_or_create_by_username_and_password(username, password);
	      call.resultHandler = responder.result;
	      call.faultHandler = responder.fault;
	}
}
}

ActiveRecord dynamic finders are finder methods that are automatically generated by Rails based on the column names in the table that the ActiveRecord wraps. For example, the users table has three columns: id, username, and password. So, the User ActiveRecord class automatically generates a method called find_by_username, and a method called find_by_username_and_password, and so on. Click here to read an article that provides an in-depth explanation of how dynamic finders work.

As you can see, there are two dynamic finders that are currently being used in the UserDelegate class: find_by_username_and_password(username, password); in the loginUser method which finds an existing user, and find_or_create_by_username_and_password(username, password); in the registerUser method which creates a new user if it does not find one that matches the provided username and password.

Ok, now that you know how invoke ActiveRecord methods inside of Flex I should note that I think that you should only do this where it really makes sense to do so. The obvious drawback to this approach is that you have to make a call to the server for each method that you invoke. In general, it is best to keep this type of logic in a server-side service class (like the ProjectService and the IssueService). I’ve only included this functionality in Issue Tracker Sample app to show that it is possible. I plan to remove this code in the next update of the application and move into a UserService class.

Ok, I am finally back from vacation.

This is the third post in a series that covers certain features of Issue Tracker sample app (view, source) that I added to the Flex RoR SDK.

The first post explained how to set up the application.

The second post covered how you can get WebORB for Rails to return typed objects to Flex using the [RemoteClass] metadata tag.

This post covers how to use ActiveRecord Associations with WebORB.

What is an ActiveRecord?

For those of you who are new to Rails, let’s start with a quick discussion of ActiveRecords and ActiveRecord Associations. The ActiveRecord class in Rails is an implementation of Martin Fowler’s Active Record design pattern. Martin defined an Active Record as:

An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.

The Rails ActiveRecord class obviously does a lot more than this, but for this tutorial all you need to know is that an ActiveRecord is an object that wraps a table in a database.

What is an ActiveRecord Association?

So, what is an ActiveRecord Association? Well, as you can probably guess, it is association between ActiveRecord objects, or in other words it is an association between tables in a database.

Rails Conventions

To understand how ActiveRecord associations work we need to cover a couple of Rails conventions. As you might know, part of the power of Rails framework is that it favors convention over configuration. This means that if you adhere to Rails conventions it will take less code to get your apps up and running.

Here are two Rails conventions that are relevant to this discussion:

A tables primary key column should be named id.

Foreign keys should be named <class>_id.

For example, in the Issue ActiveRecord class in the Issue Tracker Sample App there is a attribute named project_id. This attribute contains the value in the id attribute for the project that the issue belongs to.

Types of Associations

There are several different types of relationships that you can create between tables using ActiveRecord Associations. They include:

has_one – one to one

has_many or belongs_to  - one to many

has_and_belongs_to_many – many to many

You can use ActiveRecord Associations to quickly create complex relationships. For example,

has_many :contributors, :through => :contributions, :uniq => true

This tutorial focuses on the has_many association.

Creating an Active Record Association

To see how to create a has_many association between to two ActiveRecord objects, open up the Project class. The class file is located in C:\rails\rails_issue_tracker2\app\models.

Inside the Project class file you will see the following:

class Project < ActiveRecord::Base
      has_many :issues, :dependent => :delete_all
end

This tiny piece of code does a couple of things. The first half (has_many :issues) creates a has_many association between the Project ActiveRecord and the Issue ActiveRecord. The second half (:dependent => :delete_all) states that the issues associated with a project are dependent on that project and that they should be deleted if the project is deleted. In other words, if you a delete a given project, this piece of code tells Rails that all the issues associated with the project should be deleted also.

Now, to see how we can put this association to work, open up the ProjectService class. The ProjectService class file is located in C:\rails\rails_issue_tracker2\app\Services.

In the ProjectService class you will see the following method:

def getProjects(user_id)
     projects = Project.find(:all, :include => [:issues],
 				    :conditions => ['user_id = ?', user_id])
end

Pay special attention to this bit of code: :include => [:issues]. This argument tells the find method that for each project it finds, it should also go out and get all of the issues that are associated with that project. Rails knows how to do this because of the conventions that I discussed above. For each project that the find method returns, Rails inspects the value in the id column, then it goes out and finds all of the issues that have this value in the project_id column. Now each project will have an attribute named issues that contains an array of all the issues that are a part of that project.

So, now with this code in place, when you run the Issue Tracker Sample App and log in, the GetProjectsCommand gets executed on the Flex side of the app. This command calls the getProjects method in Rails. The getProjects methods finds all of the projects where the value in the user_id column equals the user_id for the current user. At the same time, the find method goes out and finds the issues for each project and packs them up into an array. WebORB wraps all of this up and returns the projects to Flex as ProjectVOs using the [RemoteClass] metadata tag.

By default, WebORB takes objects that are typed as arrays in Rails and sends them to Flex as arrays. So, the issue array that is part of each project ActiveRecord instance in Rails is sent to Flex as an array. This is fine for most purposes, but if you want to be able to do databinding then you need to use a collection of some sort (e.g., ArrayCollection, XMLCollection, etc). My simple solution to this problem was to write a setter function that takes the issues array and stores it in a ArrayCollection named issuesCollection. Now you can bind your components to the issueCollection and they will be automatically updated when the collection is updated.

package com.rxr.issuetracker.vo
 {
 	import com.adobe.cairngorm.vo.IValueObject;
 	import mx.collections.ArrayCollection;
  	[Bindable]
 	[RemoteClass(alias="com.rxr.issuetracker.vo.Project")]
 	public class ProjectVO implements IValueObject
 	{
 	         public var id : int;
  		public var user_id : int;
  		public var title : String;
  		public var issueCollection : ArrayCollection = new ArrayCollection();
  		public function set issues ( value : Array ) : void
 		{
 			issueCollection = new ArrayCollection(value);
 		}
	  }
 }

ActiveRecord Association in Action

When you run the Issue Tracker Sample App and log in the Flex app runs the GetProjectsCommand, which calls the getProjects method in the ProjectsService (see above) in Rails. Now that there is a has_many association between the Project ActiveRecord and the Issue ActiveRecord, this single service call returns all of the projects for a given user, and all of the issues associated with each project. So now you can take the result of this single service call (see below) and cache it on the client, which will significantly reduce the number of calls that you have to make to server for the rest of the session.

As always, drop me a line if any of this is unclear or incorrect.