The thought occurred, what if we did a side-by-side comparison of the
'normal' way of restful controllers, to using the various restful
controller abstractions, like resource_controller and
inherited_resources, for the entire app?
So I set out to do so. These were my goals:
- start from a baseline commit
(http://github.com/bostonrb/bostonrb/commit/9f92569536ea54952d8d873708b0c9cb8e7145fc)
- use the abstraction whenever boilerplate rest stuff is used
- tests and stories cannot be changed, and must pass
Here are the results:
The original code:
http://github.com/bostonrb/bostonrb/tree/master
Using resource_controller everywhere:
http://github.com/bostonrb/bostonrb/tree/resource_controller
Using inherited_resources everywhere:
http://github.com/bostonrb/bostonrb/tree/inherited_resources
With that, I'd like to open discussion on how good/bad it is to use
these abstractions, and how the implementation compare.
Additionally, if you have another contender you'd like to see battle,
just fork on bostonrb on github, make a branch for it, and report back
here.
- Josh
On Tue, Aug 4, 2009 at 3:12 PM, John Norman<jo...@7fff.com> wrote:
> How about saying now which way you prefer and why?
inherited_resources
It has more features and a more natural API.
More features: I18n API makes flashes as easy as a YAML file:
en:
flash:
actions:
create:
notice: "{{resource_name}} created."
update:
notice: "{{resource_name}} updated."
destroy:
notice: "{{resource_name}} deleted."
users:
update:
notice: "Account updated."
employees:
create:
success: "Employee added to company."
More features: has_scope encourages pushing logic into named_scopes on
the model.
More natural API: "No tricks, no DSL, just Ruby."
def destroy
super do |format|
format.html { redirect_to root_url }
end
end
but can be shortened to:
def destroy
destroy! do |format|
format.html { redirect_to root_url }
end
end
Nice inline overrides:
def create
@project = Project.new(params[:project])
@project.something_special!
create!
end
Success and failure blocks:
def update
update! do |success, failure|
failure.html { redirect_to project_url(@project) }
end
end
Some of this API stuff is just preference, but I prefer it.
--
Dan Croak
@Croaky
Some its code has historically ended up in Rails core.
respond_to and respond_with:
http://www.loudthinking.com/posts/37-bringing-merbs-providesdisplay-into-rails-3
http://github.com/rails/rails/commit/09de34ca56598ae5d0302a14715b2a11b6cc9845
--
Dan Croak
@Croaky