[3.0] Ext.Direct Routers for Rails and Merb

[christocracy]

I released a beta version of the Ext.Direct router for Rails yesterday.
http://rubyforge.org/projects/rails-extjs/

See README.rdoc where I wrote a 3-step setup process.

>sudo gem install rails-extjs-direct

This gem is very new and I have yet to handle file-uploads from multipart forms but that won't take more than 2 hours. The Rails router is implemented using Rack Middle Ware so you need Rails 2.3.2+. The Rails gem will route transactions to multiple ApplicationControllers during a single Ajax request.

The Merb gem has been around a little longer.
http://rubyforge.org/projects/merb-extjs/

>sudo gem install merb-extjs-direct

The Merb gem is implemented with merb-parts so Ext.Direct requests will be routed to actions within your Merb::PartControllers. I'm looking forward to something like merb-parts in Rails3.

Both the Rails and Merb gem have a very small code footprint, there's really not much to them. If anyone wishes to contribute to either of these projects, let me know and I'll provide access to the repos on Rubyforge.

I foresee adding more gems to these namespaces "merb-extjs" and "rails-extjs" to assist with Rails/Merb development with Ext JS.

Please let me know of any issues or suggestions.

[edspencer]

Thanks for putting this up.

I'm a Rails guy too and have been looking through this - what I'm finding difficult at the moment is getting any 'editorial' kind of info about what Writers and Direct actually do... is there anything I can look at about this?

Poking around at the gem code I can see how it's looping through a bunch of 'requests' inside the single request received, but how do you provide error feedback this way? If I want to execute a few actions and they're bundled into a single Direct request, how do I regain control if one of them fails? What do I do if my save doesn't pass validation, or my load hits a 404?

It looks like REST is out of the window with this approach too - do you think that makes it harder for other applications to use the same server API?

I hope I don't sound negative... I just don't understand how it's meant to work at the moment!

[christocracy]

Poking around at the gem code I can see how it's looping through a bunch of 'requests' inside the single request received, but how do you provide error feedback this way?

In SVN for that gem, I've added a rescue_action to the controller mixin Rails::ExtJS:irect::Controller. The rescue_action is looking for exceptions of class XException. XException is provided by the rails-extjs-direct gem. Notice how it simply returns an Ajax response of type XExceptionResponse. Ext.Direct is prepared to receive this type of response (simply a json response having "type":"exception")

def rescue_action(e)
      if (e.kind_of?(XException))
        render :json => XExceptionResponse.new(@xrequest, e)
      else
        raise e
      end
    end

Raising an XException in a controller action:

class UsersController < ApplicationController
    include Rails::ExtJS::Direct::Controller

  def create
      raise XException.new("A create exception!!!")
  end
end

[ttsuchi]

Thanks for the gem! I'm starting to take a look at the gem today. One thing I noticed it is that it doesn't support namespaced controllers yet... (Well, I'm sure there're lots of things that's not supported yet, but this was the first roadblock I encountered.) I want to use it under my "/admin/*" URL, and so want to invoke Admin::SomeController instead.

So looking at the gem source, I made the following changes:

def initialize(app, rpath)
...
    @ns = rpath[0...rpath.rindex('/')]
end

def call(env)
...
  request_env["PATH_INFO"] = "#{@ns}/#{controller}/#{action}"
  request_env["REQUEST_URI"] = "#{@ns}/#{controller}/#{action}"
...
end

and in my environment.rb

config.middleware.use Rails::ExtJS::Direct::RemotingProvider, "/admin/direct"

So basically, when "/admin/direct" router is defined, this would try to forward reqs to "/admin/*" URL. This is not a great solution - this way, the app can handle only one namespace. Maybe a better approach is to pass the namespace param from Ext.Direct (like baseParams: {ns: '/admin'}) and get that value from there, but I haven't looked into the Ext.Direct.addProvider yet to know if that's possible

[ttsuchi]

Also, maybe the default of the @params in XRequest should be a Hash ({}) as opposed to array ([])?

[chriss]

You can solve this problem by modifying the remoting_provider.rb file from the gem( ruby\gems\1.8\gems\rails-extjs-direct-0.0.3\lib\rails-extjs-direct\rack).
Replace

controller = req.delete("action")

with

controller = req.delete("action").gsub("::","/")

The only disadvantage is that you'll have to call your provider by
window[Namespace::Controller]

[somebee]

I have created a merb-router myself, which does not use Parts at all. It exposes all the public controllers and actions automatically (has a helper for generating the direct-api javascript), and maps to the exact same controllers as your public api etc.

This is done with merb-action-args, so that that I can do this:

class Topics < Application
  direct :expose => :all 
	
  def show(id)
	@topic = Topic.get(id)
	display @topic
  end

end

When you include the js-helper, you can automagically call:

Topics.show(10, function(topic){ /*callback*/}) in your client-code.

But the same action can also be accessed via regular http, like:
http://yourapp/topics/10.json => {:id => 10, :title => "Hello", ...}
Or without resource-routes:
http://yourapp/topics/show.json?id=10 => {:id => 10, :title => "Hello", ...}
 
So, with merb-action-args there is no need to have duplicate code.
The only thing you need to set it up is to add this to router.rb:

Merb::Router.prepare do

  direct("/rpc.json") # or the url you want to use

  ...

end

I'm planning on releasing it on github, but the code itself is still a little messy, so need to do some cleaning first :-)

[plaak]

Chris,

Thanks for the rails code! This seems a much cleaner approach han trying to directly request rails' RESTful URLs and deal with ajax requests in multiple places.

A few questions/coments though:

1) It appears to completely by-pass rails authenticity token step. This means that any malicious individual could directly access your /direct path and pass json encoded parameters onto the controller.... thereby facilitating CSRF attacks. I would think it would be pretty simple to pass an authenticity_token property into the provider when it's instantiated and modify your rack code to make it required (perhaps as an option)...

2) It seems that the javascript "model" name must exactly match the name of the controller. In other words, I'd like to use the singular form of each recordset like I do with my rails' models, but most of my controllers are plural. It'd be neat if I could use either and the middleware resolve which, i.e., if the singular form of the controller does not exist, check for the plural one...

Maybe when I have time, I'll make the changes myself....

Thanks again,
Pete

[christocracy]

Would you like SVN access to the gem?

[plaak]

Sure, I can't make any promises though :-)