Ingo Weiss

Resource Awareness

2010-05-10T00:00:00Z

Resource Awareness

May 10, 2010 Ingo Weiss

Resources have been a big topic in Rails ever since DHH’s keynote of 2006. All the more surprising I find the fact that four years later, the concept of resources in Rails is still largely limited to coding conventions materialized as generators (the scaffold and resource generators) and macros (such as the resource/s routing DSL methods) and conspicuously unavailable to code at runtime. A Rails application does not know what resources it exposes, for example, nor does a controller know which resource it is handling. If you want to take advantage of the predictable behavior of standard Rails resources and jump to the next level of abstraction (as we do in a current project), however, then this is exactly the kind of information you are likely to need.

In Rails the term ‘resource’ is most commonly used as representing the set of routes generated by the resource/s routing DSL methods (We are really talking about a group of related REST resources when we talk about a resource in Rails). During the invocation of resource/s in the Rails initialization sequence, instances of ActionDispatch::Routing::Mapper::Resources::Resource are created representing the resource. Those instances are only used for route instantiation, however, and unlike the route instances themselves who are kept around and accessible at runtime via Rails.application.routes, they are thrown away after the routes for the resource are instantiated.

What I would like to see happen is for the ActionDispatch::Routing::Mapper::Resources::Resource class to be promoted to encapsulate all relevant information about a resource (not just what’s needed for route instantiation), and it’s instances to be kept around and be accessible at Rails.application.resources. I plan to write a patch to that effect, but needed the functionality now so I wrote the resource_awareness gem as a short-term fix. The gem makes information about the resources defined via resource/s available at Rails.application.resources, as a collection of Rails::Resource instances (please see the README for more information about their attributes). It also gives controllers a resource method returning the resource they are handling, if any.

I believe that making this information available to code at runtime opens the door for interesting new abstractions, and I hope to write about some in further posts.

Fun with ResourceAwareness and ActiveResource

2010-05-12T00:00:00Z

Fun with ResourceAwareness and ActiveResource

May 12, 2010 Ingo Weiss

In my last post (Resource Awareness), I introduced the resource_awareness gem and the thoughts behind it. In this post I would like to explore one interesting thing you can do with it, namely expose an application’s resources as a resource in turn which makes it very easy for other applications to dynamically create ActiveResource clients for interacting with those resources. Let me demonstrate:

Suppose you have an application with the following resources:

# config/routes.rb
resources :countries, :controller => 'countries' do
 resources :cities, :controller => 'country_cities'
end

Now let’s expose those resources like so:

# Gemfile
gem 'resource_awareness'

# config/routes.rb
resources :resources

# app/controllers/resources_controller.rb
respond_to :xml

def index
  respond_with Rails.application.resources
end

Information about the app’s resources is now available at /resources.xml. Now let’s start a server at port 3000 and fire up a console for another app to interact with the first app. First, we need an ActiveResource client to retrieve the first app’s resource information:

# console
> class RemoteResource < ActiveResource::Base; self.site = 'http://localhost:3000'; self.element_name = 'resource'; end
> RemoteResource.first.attributes
=> {"id"=>"country_cities", "path_prefix"=>"/countries/:country_id", "singular_name"=>"city", "path"=>"/countries/:country_id/cities", ...}

Turns out that two of the resource’s attributes, singular_name and path_prefix, is all we need to create an ActiveResource client for it. In most real world cases we would probably want to do this dynamically and would not want to create named classes blindly, so let’s use an anonymous ActiveResource subclass instead:

# console
> r = RemoteResource.first
> client_class = Class.new(ActiveResource::Base){self.site = "http://localhost:3000#{r.path_prefix}"; self.element_name = r.singular_name}
> client_class.create(:country_id => 1, :name => 'Berlin').attributes
=> {"name"=>"Berlin", "created_at"=>Wed May 05 10:51:31 UTC 2010, ... }

Just a fun experiment at first, this approach has already proven very useful in a current project of ours which I hope will be the topic of another post. I could also imagine this being useful in circumstances where you would otherwise use something more heavyweight such as WADL