The Mechanical Turk

Edge rails recently added support for multiple view paths. Very cool. This means you can ship a plugin complete with views, and have your controllers use those views (without copying them to app/views), and you get overriding for free.

inherit_views (svn and rdoc) is a plugin that allows you to do something similar, but within a controller hierarchy. (This is not a replacement, or duplication of 'multiple view paths')

Example

Here's an example of the syntax

class PostsController < ApplicationController
  inherit_views
end

class UserPostsController < PostsController
end

UserPostsController will look for a particular view in app/views/user_posts, if it doesn't find it, then it looks in app/views/posts.

For the example above, you may wish to change some aspects of just index.rhtml, and leave the other views alone. Previously you would have to set up a bunch of erb (or haml, or whatever) files that either duplicate, or render the unchanged files. No longer.

render_parent

The inheritance model is familiar, so why not have the familiar 'super' construct in views?. You can now:

posts/_resource.rhtml:
  <%= post.title %>
  <%= link_to 'comments', comments_path(post) %>
  
user_posts/_resource.rhtml:
  <%= render_parent :locals => {:post => post} %>
  <%= link_to 'my comments', user_comments_path(@user, post) %>

Why?

Two main reasons:

1. Making life for STI users (I'm a heavy user) easier. This is a classic case where inheriting views makes life easier. It's also easier if you use something like resources_controller to decouple the model name form the view (instead of @my_model - which then becomes @my_model_subclass, use a local, or in the case of resources_controller resource)
2. Providing the basic tools to build auto-scaffold type systems. I think the idea of these systems is great - but they never work quite right for me. For me, they cover too much ground, make too many assumptions. So, I'd like to have a set of tools that help me easily build one of these auto-scaffold things for use in just one, or a few projects. inherit_views and resources_controller are two such tools.

Update: check out resource s controller update

Update: point 3 below (broken in rails < edge) is now solved. (non-edge) Rails <= 1.2.2 users should also install this plugin.

(this is a followup to this entry)

There were some problems with resources_controller as released a couple of weeks ago, including:

• No support for name_prefix, which crippled the url_helpers
• Limited support for polymorphic resources
• Broken in rails < Edge, due to the fact that scoped creates for associations are new.
• Lack of test support to show me the above

The 1st, 2nd and 4th points have been thoroughly addressed in the latest release, and if you run the tests you'll find out if your version of rails is susceptible to the 3rd point. The solution to the 3rd point should be pretty trivial and will appear soon.

(Thanks to Igor Alexeiuk for pointing me in the right direction on the above, and for contributing some code for name_prefix stuff)

Here's an example of what you can do:

class TagsController < ApplicationController
  resources_controller_for :tags
  nested_in :taggable, :polymorphic => true, :load_enclosing => true
end

The above controller can be used to service all of your models that have tags, wherever they're located in the resource schema. The controller will load the enclosing resources (raising RecordNotFound if the relationships don't match) and the named routes will also work.

Take a look at the test app to see what the new syntax is like, and what the plugin is capable of here

Update: check out resource s controller update

Update: check out this entry

Update: for Rails <= 1.2.2 users, also install this plugin

So you want to write a quick and dirty REST server:

• Models, ActiveRecord mmmm nice and DRY tick
• Routes, super easy - even nesting routes! tick
• Controllers - oh crap, we're talking scaffoling, then changing like 8 lines of code in each one of the nested controllers - there's major duplication - there must be a better way...

The above inspired me to come up with the resources_controller plugin (svn, and rdoc).

(If you're interested in how this works, and you don't want to read the rdoc, read my post at rails weenie)

Here's an example, your usual forums/posts/comments one. See the docs for more examples.

  class ForumsController < ApplicationController
    resources_controller_for :forums
  end
  
  class PostsController < ApplicationController
    resources_controller_for :posts, :in => :forum
  end
  
  class CommentsController < ApplicationController
    resources_controller_for :comments, :in => [:forum, :post]
  end

Couple of caveats: you need rspec to run the tests, and there's no resource_controller (singleton resource controller) plugin as yet.

Please let me know how to make it better.

Update

2/Feb: Much better docs, and a few improvements