RubyAMF at RailsConf Europe
Simeon Bateman put together a nice demo app for RailsConf to show off the power of Flex and Rails. He’s got three examples – an HTTPService example, weborb, and RubyAMF. Check them out.
Archive for Flex
RubyAMF Exposure at MAX
Be sure to check out the Flex on Rails session at MAX with Tony Hillerson of EffectiveUI.
Here’s the session description:
Learn how to integrate your Flex applications with a Ruby on Rails back end. Topics include remoting, using ActiveRecords in Flex, and the Flex/RoR SDK. Finally, learn how to deploy your Flex application to Adobe Integrated Runtime (AIR).
RubyAMF exposure will be limited, but thanks goes to Tony for even considering RubyAMF to be part of his presentation. Thanks Tony!
Rant – Build Tool Mashup with Ant and Ruby
Rant is a simple tool I’ve been working on here and there, and it’s at a place where I’d love to get some eyes on it.
Rant is a mashup of ANT and Ruby for the best of both worlds. Ant is useful for a lot of little tasks – setting up hierarchal chains of execution, executing scripts, moving files, generate templates etc. But then there are times when I wish I could just script parts of the build process. Now you can with Rant. As mentioned, it’s a mashup of ant and ruby. During the build process, an entry point into a ruby file is made that allows you to execute commands, which can be whatever you think of in ruby.
Rant is an all around build tool for those developing projects in Flash or Flex, but don’t want to use Flash IDE or Flex Builder.
Currently I’ve only been able to test this on a Mac, and am looking for some eyes to make sure this works in Windows / FlashDevelop. Give it a shot! Download it here.
Please check out the readme file as well. This is a great place to start.
See the readme file.
RubyAMF 1.3.3
Ok folks, here is 1.3.3. This release has a few really important fixes in it. In case you didn’t notice, I silently released 1.3.2b into the rails installer. That had one serious bug fix, and 1.3.3 has a few more fixes that I came across that are somewhat serious. So please update to 1.3.3.
RubyAMF 1.3.2a
It’s that time again. Here is RubyAMF 1.3.2a. This has a number of really good fixes in it.
First I’ve added support for BigDecimal. What does that include? Native NaN, Infinity, -Infinity de/serialization. Now those values will be handled by RubyAMF. There is also top level functions isNaN and isFinite to support those new values.
Here is a list of the new pieces that go into BigDecimal support on the Ruby side:
isNaN / isNaN? isFinite / isFinite? NaN #not a number. Infinity #infinity (Infinity / Math.POSITIVE_INFINITY) NInfinity #negative infinity (-Infinity / Math.NEGATIVE_INFINITY)
As an example, immagine we do this as a service call from Flex:
myRO.getNaN()
And in Ruby:
def getNaN #LITE: return NaN #RAILS: render :amf => NaN end def getInfinity Infinity end def getNinfinity NInfinity end
The result will be NaN in the player. Same goes for Infinity / NInfinity. Note that AMF0 only supports NaN.
I’ve also cleared up an issue with outgoing Date objects having problems being cast in the Flash player. The problems don’t happen anymore, but the solution was to skip writing any references to other Date objects in the AMF stream.
Previously, the player would get hung up on referenced Date objects while deserializing the AMF – which caused the player to throw a TypeError. The strange thing is that even though there was a casting error, the dates were still usable and correct.
Now I just force it to write every Date object to the stream, which fixes this. But is this a problem with the player?
See the release log for more info on this release.
1.3.2a is now in the Rails installer as well.
More Updates Coming
I’ve added better support for params hash mapping. So those that tried to do the following but ended up failing, can now do it.
def update
u = User.find(params[:id])
u.update_attributes(params[:user])
if u.save
respond_to do |format|
format.amf { render :amf => true }
end
end
end
That wouldn’t work previously. So I have an update for this in /trunk that now handles this.
Actually, here’s a good time to explain how remoting parameters map to the params hash in rails.
-All incoming VO's get put into params[:CLASSNAME]. EX(params[:user]). -If an Incoming VO is not an active_record, but a custom vo which maps to a fully qualified class path (:map_to => 'my.package.class.MyCustomVo'). It will be put in params[:mycustomvo] -All incoming parameters ALSO get put into their index. EX(user = params[0]). -For incoming active_record VO's, the params[index] is an update hash. -If the first param is an Object or VO, it's property values are merged into params. (params[:id], params[:firstname], etc..)
Make note that the only time an objects properties are merged into the params hash is if it’s the FIRST parameter in the remoting call. As usual – if anyone has an idea to better this just let me know.
These updates are in /trunk for now, and I will release 1.3.2 as soon as I get BigDecimal support in.
RubyAMF 1.3.1
1.3.1 adds deep result adapters. You have to opt in to this (in the adapters_config) file. But this means that even if you send results wrapped in array’s it will correctly send back what you’re expecting.
So if you do this:
def my_method u = User.find(:all) p = People.find(:all) a = Array.new(u,p) render :amf => a end
The results in Flex / Flash will be an array with two elements ([0],[1]). Which contains another array of objects. Just like you would expect.
As mentioned, you have to turn this on specifically in the adapters_config file. As this has the potential to slow everything down. So it’s off by default. This is the same for both RAMFL and RAMFR.
1.3.1 is now in the Rails installer as well.
ruby script/plugin install svn://rubyforge.org/var/svn/rubyamf/tags/current/rubyamf
Rails Controllers and rescue_action
Here’s a random but useful note. If you make a remoting request to a controller, but an exception happens and you want to be able to pipe it back to flash. Use rescue_action in whatever controller you’re calling.
Here’s an example:
require RUBYAMF_HELPERS + 'fault_object'
class UsersController < ApplicationController
def rescue_action(e)
respond_to do |format|
format.amf { render :amf => FaultObject.new(e.type, e.message) }
end
end
def list
raise ArgumentError
end
end
In this example, making a call to the list method simply raises an ArgumentError for an example, but ends up being sent to the rescue_action method, which in turn renders AMF for you.
Then in Flex / Flash, you can inspect these fault object properties to see some more detail:
private function onFault(fe:FaultEvent):void
{
trace(fe.fault.FaultString);
trace(fe.fault.FaultCode);
trace(fe.fault.faultDetail);
trace(fe.fault.rootCause);
trace(fe.fault.extendedData);
}
Sweet!
See api.rubyonrails.org -> ActionController::Rescue for more information.
RubyAMF 1.3 RC2 revision 742
Here is another revision for 1.3 RC2. This is about as close as we get to a 1.3 Final. This might end up being the 1.3 Final build. Here’s what’s changed:
#Added in FaultObject handling when sending back FaultObjects from Controller’s, it had been stripped out when rewriting the rails plugin.
#gzip works now, strange as I didn’t change anything specifically for it.
#split vo / adapter configs into two files, now the configs live in rails/config/rubyamf. For LITE, the configs are now in rubyamf/services/config/.
#added ValueObjects.rails_parameter_mapping_type, to specify what gets put into params[:] hash.
The most important one to note is the last one. This option lets you decide how you want incoming VO’s stored in Rails’ “params” hash. As either the actual ActiveRecord instance, or an update hash that you can use for creating new instances of ActiveRecords (u = User.new(params[:user]))
1.3 RC2 revision 742 is now in the Rails installer
Give it a whirl!
Remoting Call Parameters and Mapping them to Rails’ Params
I put a quick update into RC2 (in svn) that puts Value Objects in the params[] hash by their instance type. So if you send a Person VO from Flex, it will get put in params[:person]. I have a slight dilemma and I wanted to hear from everyone who has been using RubyAMF to see what they might like better.
The dilemma is when you send a VO from Flex to RAMF, it automagically gets turned into an ActiveRecord instance. In the above example. params[:person] is already an instance of an ActiveRecord. And here comes the dilema. Some people want to be able to call p = Person.new(params[:person]). But because it’s already an ActiveRecord instance an exception is raised.
So what would you rather have? params[:person] == ActiveRecord, or params[:person] == update hash. Or maybe you would rather let the ActiveRecord instance be in params[0], and the key/val be the update hash? Or would you want to be able to toggle how RubyAMF handles that kind of parameters mapping?
I’d like to hear from some others, I don’t want to do what I like when the majority possibly likes it another way.
