Uncategorized
Using Flex 1.5 with ARF! and Reactor and Coldspring
I have gotten to work on a couple flex applications lately. Mostly just a pretty GUI for some data stuff. Normal CRUD operations. When you get right down to it is your average boring stuff.
So I decided that I would see what is required to get a couple of the popular CF ORM tools to work with Flash Remoting. I first implemented ARF! then Reactor. But not satisfied with the game I played I proceeded to set up ColdSpring with the 2 frameworks so I could use the Remoting Tools built into that framework.
Before I get into using the tools, I mentioned above, I think it would be a good idea to cover some basics on making remoting work.
Flex has made flash remoting a trivial chore. By using the mx:RemoteObject tag it is very simple to access your cfc and pull out your data. A simple remote Object looks like this:
result="resultHandler(event.result)"
fault="faultHandler(event.fault.faultstring)"
id="ro" />
The end point attribute is your domain plus the flash gateway url. The source is then the path to the cfc you are trying to call. The livedocs will explain the other attributes if you are trying to make this work :)
With this set up in your Flex file you could activate a remote method like :
Now lets just for a minute take a look at what we are actually calling on the other ColdFusion backend. We might have a cfc that has a function that looks something like this.
SELECT * FROM USERS;
That is all that is required in CF to return this data to flex. In our remote object above we reference a resultHandler() method that should deal with our results when they come back. An example of how our result handler could work might look like this:
public var users:Array;
public function resultHandler(results:Array):Void{
users = results._items;
}
The code above uses an array called users as the dataProvider for a data grid in flex. In the resultHandler method we populate the users array with the results of our remote call. In other words we set users equal to our members from our query.
Now if you are new to this you might wonder how we were able to set an array object with the results of a query. Part of the magic that happens in our remote gateway, is that when we return a query from a cfc, it actually turns that into an array of objects.
The trick then is getting the array of objects to be an array of a particular kind of object. And to do this justice I will just refer you to the article that explained it to me over on dirk’s site.
But to summarize what needs happen there are 3 steps. The first is that your object that gets returned from CF needs to have a public property called “_REMOTECLASS”. The value of that is the full path of the cfc. The second and third pieces has to do with configuring Flex. I use a function that gets called on initialze of my application. In this you set the static property that the Flex remoting classes use to identify what type of object is coming from cf. I use something like this.
var dep1:path.to.vo.Member;
public function initApp():Void {
mx.utils.ClassUtil.FLEX_CLASS_FIELD = "_REMOTECLASS";
}
The last peice of the magic that happens in the flex remoting gateway, is to have a dummy var that is the AS type that your cf object should be mapped to. I have included this in the code above. Then the third peice has to do with how your AS object gets mappend when you send data back to the CF gateway. In your AS class you need to use the registerObject line and map the cf type to the as object.
static var registered=Object.registerClass("path.to.MemberTo",path.to.vo.Member);
And with those pieces in place you should get your objects returned as the correct types. I will be showing examples of this as I publish the code for the various versions I have created. So stay tuned.
10 Feb 2006 Simeon

Hi Simeon,
Nice post! Just wanted to point out that with vanilla CF, passing custom objects, hierarchies of custom objects, etc. is problematic. Sam Shrefler just released a CF demo for Arp that uses Tartan and overcomes these limitations (Tartan has a base class with workarounds for these issues.) It might be worth looking into.
He released the source on his blog:
http://www.shrefler.net/blog
Thanks Aral,
Yeah i saw sams post, but I have not taken a look at the code yet. I have a couple projects now that are returning Ojbects that have objects in them, and have had great luck with this. One such application returns a project object that has an array of tasks, and each task has an array of log items. As long as I added the _REMOTECLASS property to them, and made sure I had a dependency in the root application for each of the objects I was returning, I havnt had any problems. And that includes returning Objects that were built by ARF! and Reactor persistence frameworks.
But i will post more on how I used each of these and perhaps someone will be kind enough to point out where they have had problem in what I have done.
Oh, and although i have not done it with tartan yet, I have done it with coldspring. ColdSpring also has some utilities for by passing the problems I ran into with vanilla objects.
Hi,
the use of the _remoteClass field is deprecated in Flex 1.5 and shouldn’t be used. A better way to map CF "objects" to their AS counterparts is to instantiate flashgateway.io.ASObjects in CF, set their type and fill them with data. Ok, this is also just a workaround but the it better mimics the Flex 1.5/Java route.
Dirk.
Thanks Dirk,
I appreciate you taking the time to set things straight. I am aware of the ASobject method for returning data to flex, but my exercise has been on actually returning cfc and structs from CF. Once we populate the ASObject with the data from our object we are not really returning our objects anymore. Not that it really matters too much.
I imagine since CF(via mystic) has a whole new method for this connection in Flex 2.0 that even the java method of connection is depricated for CF’s part now :)
But thanks again for all the content on your site. its a great resource.