Or from the current tag:
script/plugin install http://rubyamf.googlecode.com/svn/tags/current/rubyamf

Now, for anyone interested, what was breaking was Rails 2.1’s forgery
protection, which stops cross site scripting attacks by placing a
security code in HTML and Ajax forms and verifying that that’s the
right code on the Rails side.
My fix was just to add the AMF mime type to the list of mime types
that aren’t checked for forgery protection, alongside XML and JSON. I
think it belongs there, because there’s no way that I know of to hook
into the Rails forgery protection.
To do the same type of thing from a Flash app would be a bit of a
different process, and I’m not quite sure what the best way to think
about that is, nor if it’s actually a problem we need to worry about
anytime soon. Any thoughts?
Upshot: RubyAMF 1.6 for Rails 2, RubyAMF 1.6.1 for Rails 2.1.

Cross posted from (http://groups.google.com/group/rubyamf)

So here’s the scoop. Aryk Grosz from MixBook contacted me about using RubyAMF and some experiences he was having. RubyAMF would start to slow down with large complex data structures even slower than WebORB depending on the size, Yikes! Aryk had put time into optimizing RubyAMF and you would not believe the results we’re getting.

I went down to Mixbook in San Jose on Sunday and spent a little time with Aryk ripping apart RubyAMF. So we’ve pretty much re-written RubyAMF, here’s a brief rundown of what’s going on.

First let’s talk restructure. We ripped out 60% of the code base which was legacy from RAMFL. I won’t go into the gory details but we’ve re-arranged a lot, changed a lot of names. For example ValueObjects are now ClassMappings. Which is more appropriate because RAMF has full class mapping support. We’ve also put an init.rb file in the plugin so all the requires get done on application startup.

There are a couple other features we’ve added to class mapping definitions, such as the :associations, :attributes, and :ignore_fields properties. The :ignore_fields is just like it sounds, for a specific class mapping you can ignore specific properties on it. You can also define a global ignore fields like so: ClassMappings.ignore_fields.

The :associations and :attributes are for performance reasons. You aren’t required to use them, but if you do it speeds up the serializer even more. We’ve also change the names of :incoming / :map_to / utgoing to :actionscript / :ruby.

Performance! This thing is about 5x faster. As an example, a data structure of about 1500 objects that’s used in Mixbook takes around 35 seconds with WebORB. RAMF averages 2.4 seconds. Sweet! You can even see the speed increase on one object. It’s that much faster.

We also decreased the size of the data transfer. As an example, let’s say an AMF message was 250K, it would now be about 100K. That’s a huge difference.

That’s just a small preview of what’s going on. Sorry for the inconvenience of not getting 1.3.4 done last week, but as soon as we started these changes and optimizations – 1.3.4 was obsolete.

So hats off to Aryk for the help, he did a most of the speed optimizations and has been refactoring and writing a ton for RubyAMF. Thanks for the help!

And to top it all off, RubyAMF will have it’s first “in production” customer over at MixBook. They’re working on re-factoring their rails app to use RubyAMF. Awesome!

-Aaron

As a quick example, let’s say you wanted to map the “id” property of a “User” object to the params[:id] key. Here’s how you’d do it.

Here’s an example actionscript remoting call:

 service = new RemotingService("...","UserController",3);
 service.destroy([myUser],result,fault);

And the supporting RubyAMF configuration to accomplish this mapping:

Parameter::Map.register({
 :controller => :UserController,
 :action => :destroy,
 :params => { :id => "{0}.id" }
})

This is a big improvement over the old way, which would only map the first parameter into the params[:] hash, you can decide what gets put where.

As another example. If you wanted to map the 3rd arguments “firstname” property to “params[:firstname]“. You’d do this:

AS:

 service.myaction([...,...,thirdObject],result,fault);

Config:

Parameter::Map.register({
 :controller => :UserController,
 :action => :myaction,
 :params => { :firstname => "{2}.firstname" }
})

As mentioned, this will hit in 1.3.4. Hope it’s useful -A

Hang in everyone! I’ll officially be back from vacation on the 8th to release 1.3.4 and gear up for the next dev tasks. Additionally I don’t see any major conflicts with RubyAMF and Rails 2, as there is only one entry point into Rails (aside from the rubyamf controller).

RubyAMF is getting to the point where it’s a great experience tying it in with Rails (and of course with Lite) – the fact that it works with scaffolding and in your controller with render :amf makes it a winner for me. But if people don’t use it because they can’t read the site then it’s time for an update. I love working on RubyAMF so I want everyone to have a great experience with it. Maybe this sounds weird – but I LOVE remoting. The first project I did with remoting was with MercuryCloud and Patrick Mineault. Ever since then it’s been a key part of almost every project I build. So I’m not trying to be pushy about RubyAMF at all, just know that everything I put into RubyAMF is pretty carefully thought out for performance factor and ease of use.

What do you think, time for a re-skin or color update?

• Any objects properties whether it be a basic object, or value object get merged into the params hash. ONLY the first parameter gets merged though.
• Any incoming value object also gets put into params[:classtype]. So if an incoming VO is of the type “vo.Event”, it will be put in params[:event]. This will enable you to fully use scaffolding without adding is_amf conditionals.

So what does this mean? If you send parameters correctly from Flash, there are only a few updates to get everything working correctly on the rails side. Here’s a generic example that should translate to a real working example.

RAILS:

class MyService < ActionController
  def update
    user = User.find(params[:id])
    if is_amf
      u = user.update_attributes(:name => params[:name], :email => params[:email])
    else
      user = User.find(:id)
    end
    if u
      render :amf => true
    end
  end

  def create
   if is_amf
     user = User.new({:name => params[:name], :email => params[:email]})
   else
     user = User.new(params[:user])
   end
   if user.save
     render :amf => true
   end
  end

  def destroy
   user = User.find(params[:id])
   user.destroy
   render :amf => true
  end
end

So in this example the destroy method works without having to mix in the is_amf variable. The create and update method has to mix in the is_amf variable because we’re not passing value objects back and forth.

Here is the corresponding AS3 to call these methods correctly.

AS3

function createUser():void
{
  myservice.create([{name:'asdfasdf',email:'aaron'}], onResult,onFault);
}

function updateUser(user:Object):void
{
   //user should be  => {id:1, name:'Aaron', email:'aaron@something.com'}
   myservice.update([user],onResult,onFault);
}

function destroyUser(id:Number):void
{
  myservice.destroy([{id:id}],onResult,onFault);
}

So what do we do to update the create and update methods so they don’t have to use is_amf? Value objects or _explicitType. These are two options to help you map everything the way you want. Here’s how they both work.

Value objects are simple. They boil down to a generic object with one extra piece of information – the class type. In our case. A ‘User’ class. So when you instantiate a value object, and send it over to RubyAMF, all your properties come over in a generic object, but it also sends the class type. Pretty simple. On the RubyAMF side your class type is caught and a Value Object of the same type is instantiated in Ruby / Rails. So if your value object is a User class, it is in turned mapped to params[:user].

So do we absolutely need value objects to get the params[:user] hash to be the correct object? No. RubyAMF uses a special property to handle value objects on the server side. _explicitType. If you send a generic object with the _explicitType property, it will be turned into a corresponding value object for you. It just so happens that the _explicitType is used to map a value object class to params[:classtype]. So we can use this to map our generic object to the params[:user].

Let’s look at how we can update methods so we don’t need to use is_amf.

Rails:

def create
  user = User.new(params[:user])
  if user.save
    render :amf => user.as_single!
  end
end

def update
  user = User.find(params[:id])
  if user.update_attributes(params[:user])
    render :amf => true
  end
end

AS3

function createUser():void
{
  myservice.create([{_explicitType:'user', name:'Aaron', email:'aaron@something.com'}],onResult,onFault);
}
function updateUser(user):void
{
  //uyser should be => {id:1, _explicitType:'user', name:"Aaron", email:"myemail"}
  myservice.update([user],onResult,onFault)
}

So by specifying the _explicitType property, it’s going to put an active record update_hash in params[:user]. Pretty cool. Now I’m not suggesting you use _explicitType at all times as it’s kind of a hack. You should use value objects instead. But hey, you’ll probably benefit from knowing more about RubyAMF.

Please let me know if there are any questions or suggestions for making it better.

Check out the release log for details.