I just discovered James Golick’s resource_controller plugin
http://jamesgolick.com/resource_controller after spending another
stretch of boredom making the changes to nest yet another rails
resource controller. I’d actually slowed down this time to think
about what I was doing in hopes of automating the task.
I’ve tended to use script/generate rspec_scaffold to get the skeleton
set of specs along with the model, migration, controller views, etc.
I’ve been a bit ambivalent about this, for one thing if feels a little
un-bdd to have the specs generated, but on the other hand the code
tends to be so pro-forma (at least to start out) and the generate
specs help as a regression check, and to help me think about how and
whether to deviate from things like flows between browser pages.
But it’s always ugly when I want to nest one of these generated
resources. It always seems to take me longer than it should to make
the changes in both the controller, the views, and the specs to get to
square one.
The plugin, which brings back the script/generate scaffold_resource
with new meaning turns a controller that looks like this:
class HardwaysController < ApplicationController
GET /hardways
GET /hardways.xml
def index
@hardways = Hardway.find(:all)
respond_to do |format|
format.html # index.html.erb
format.xml { render :xml => @hardways }
end
end
GET /hardways/1
GET /hardways/1.xml
def show
@hardway = Hardway.find(params[:id])
respond_to do |format|
format.html # show.html.erb
format.xml { render :xml => @hardway }
end
end
GET /hardways/new
GET /hardways/new.xml
def new
@hardway = Hardway.new
respond_to do |format|
format.html # new.html.erb
format.xml { render :xml => @hardway }
end
end
GET /hardways/1/edit
def edit
@hardway = Hardway.find(params[:id])
end
POST /hardways
POST /hardways.xml
def create
@hardway = Hardway.new(params[:hardway])
respond_to do |format|
if @hardway.save
flash[:notice] = 'Hardway was successfully created.'
format.html { redirect_to(@hardway) }
format.xml { render :xml => @hardway, :status => :created,
:location => @hardway }
else
format.html { render :action => “new” }
format.xml { render :xml => @hardway.errors, :status =>
:unprocessable_entity }
end
end
end
PUT /hardways/1
PUT /hardways/1.xml
def update
@hardway = Hardway.find(params[:id])
respond_to do |format|
if @hardway.update_attributes(params[:hardway])
flash[:notice] = 'Hardway was successfully updated.'
format.html { redirect_to(@hardway) }
format.xml { head :ok }
else
format.html { render :action => "edit" }
format.xml { render :xml => @hardway.errors, :status =>
:unprocessable_entity }
end
end
end
DELETE /hardways/1
DELETE /hardways/1.xml
def destroy
@hardway = Hardway.find(params[:id])
@hardway.destroy
respond_to do |format|
format.html { redirect_to(hardways_url) }
format.xml { head :ok }
end
end
end
To this:
class EasywaysController < ResourceController::Base
end
And the helpers make it dead easy to use these resource controllers
polymorphically (i.e. with multiple parent resources using for example
AR polymorphic associations) or in both nested and unnested forms.
Anyway, in case you can’t tell, I’m pretty pumped about the
possibilities of this plugin.
BUT
Right now it only generates test/unit testcases. I was wondering if
any RSpeccers had already gone down this road and whether or not a new
generate rspec_scaffold generator might be in the offing when this
plugin is installed. Someone asked this question from the other
direction on the resource_controller google group in November, but got
no reply.
I know I should just write it myself, but you cant blame a guy for
asking, and I’d love to hear comments on this plugin from other RSpec
devotees.
–
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/