ardes plugins available github and lighthouse
April 30th, 2008
Many of our plugins are now available on github: github.com/ianwhite
And OSS projects such as these can now be hosted free on lighthouse: ianwhite.lighthouseapp.com
The ones that you see on lighthouse have all had a good dusting off to make sure they're compliant with the very latest edge, and BC to 2.0.2. response_for is now branched to support edge and 2.0.2, but the other plugins haven't yet required this.
If you don't see one you use there, it means that I haven't deemed it being used by many people - so leave a comment to say otherwise
response_for_resources_controller
November 20th, 2007
If you're using response_for, then you might want to grab response_for_resources_controller
It simply replaces the default action modules with ones that use the response_for idiom.
This means that you can override what an action does without overriding how it responds. For example, I want a standard REST controller, that sets a protected attribute, user, on create.
class PostsController < ApplicationController
resources_controller_for :posts
def create
self.resource = new_resource
resource.user = current_user
save_resource
end # the standard response_for :create is used
end
If you don't know what response_for does, it lets you declaratively set the respond_to of an action. For example: if you want to override some aspect of the response, here I just want to change the flash message on successful create:
class LoginsController < ApplicationController
resources_controller_for :logins
response_for :create do |format|
format.html { flash[:notice = "You have logged in" } if resource_saved?
end
end
miscellany
I added save_resource and resource_saved? to rc, as a way of sharing the result of the save outside the scope of the action. Previously I've done this with valid?, but realised that this might hit the database unnecessarily in some circumstances. You can use either idiom.
introducing response_for: decorate your actions with respond_to blocks
October 23rd, 2007
If you've ever subclassed a controller to deal with a particular MIME type, say FBML, you will have had the painful experience of having to copy and paste all of your contoller's actions, adding, or replacing the fbml blocks into the code.
This doesn't feel right - and it isn't. If you have to change some controller logic - you have to remember to change it in all these subclassed controllers.
Enter response_for (rdoc here).
response_for lets you declaratively specify how your actions should respond to particular Mime types. This helps particularly when your action's logic is not simple (like a CRUD action - but it still helps there). Here's an example I just made up:
class ReportController < ApplicationController
# this puppy gets some models to collaborate to form a report
def report
@report = {}
@report[:invoiced] = Customer.find_invoiced
@report[:outstanding] = @report[:invoiced].select {|c| c.latest_invoice.outstanding? }
respond_to do |format|
format.html
format.xml { # some funky xml stuff here }
end
end
end
Let's say I wanted to make FBML responding version of this controller, normally, I'd have to copy/paste this action and add the fbml responses. With response_for, I do this:
class FacebookReportController < ReportController
response_for :report do |format|
format.fbml { # my funky fbml stuff here, accessing @report}
end
end
So, down the line, if I change the way my @report object is generated, I don't have to change my subclassed controllers.
Another example: create
You can choose to replace the respond_to block of the action as well. This means that common actions can be written, and the response can be adjusted according to your needs (resources_controller comes to mind).
Here's a standard create action:
class ForumsController < ApplicationController
def create
@forum = Forum.new(params[:forum])
@forum.save
respond_to do |format|
if @forum.valid?
flash[:notice] = 'Forum was successfully created.'
format.html { redirect_to(@forum) }
format.xml { render :xml => @forum, :status => :created, :location => @forum }
else
format.html { render :action => "new" }
format.xml { render :xml => @forum.errors, :status => :unprocessable_entity }
end
end
end
end
Let's say you want to create an FBML only version of this:
class FacebookForumsController < ForumsController
response_for :create, :replace => true do |format|
if @forum.valid?
format.fbml { # funky fbml stuff for valid record }
else
format.fbml { # and for an invalid record}
end
end
end
One last example
For many actions, you just want to tell your action to respond to particular MIME type and a template does the rest:
class FacebookUsersController < UsersController response_for :index, :show, :types => [:fbml] end
You don't need to have a respond_to block defined in your actions - the parent controller could look like:
class UsersController < ApplicationController
def index
@users = User.find :all
end
def show
@user = User.find params[:id]
end
end
resources_controller + response_for
For those users of resources_controller, response_for gives you an easy way of adding responses on an ad-hoc basis (like if only one or two of your actions need to be RSS feeds or summat)
This is the first release...
and I welcome any bug reports