June 3, 2010: Get your Kicks on Route resources :user
June 3, 2010
Posted by on
Geoffrey Grossenbach at Peepcode posted a typically beautiful post/rant about Rails routing.
DHH responded in the comments of the article on YCombinator.
Grossenbach argues that Routes are unnecessary configuration and offers a couple of options for moving the routing into the controllers, as Sinatra does. DHH responds that GG’s schemes would be challenging for large projects, and that the seven default action names are an important constraint.
Everybody’s making good points here, so lets have the debate. Here are some of my points:
- In any medium sized or large Rails project I’ve ever worked on, the routes file becomes a mess, and it’s hard to tell what’s going on. You could argue this is because the programmers have not been strictly RESTful, but I’d be more likely to say that it’s because RESTful is too inflexible for complex projects. I like the Rails 3 router changes, but I don’t see them changing this particular issue.
- There’s no question that the RESTful route stuff is significantly less accessible to new Rails programmers than basic controller/action URL’s are. It’s a lot of magic, it’s opaque, and every time I teach Rails it’s a stumbling block.
- I think I’d like to see the Sinatra style declarations available in the controller, as the Astaire plugin seems to offer. I’d be interested to see whether it winds up in a bigger mess, or whether the controller actions become clearer. I’d definitely try Sinatra routes on a small project.
- I’m somewhat ambivalent on the issue of whether scaffold code “should” be generated, or whether the fact that it is generated means that it should be abstracted further. I agree with the theory that controllers should be abstracted, but in practice I’ve found that working with tools that do that, like resource_controller, tend to lead to more hassle than not when you try to override behavior (again, I think that that amount of controller magic can also be a block for new users). I am interested to see whether the Rails 3 responder objects change this at all, and I’d like to see responders be part of the default scaffold — last time I checked, they weren’t.
I know I’m supposed to be outraged at AT&T changing their data plan pricing to remove the “unlimited” option. And I’d probably be kind of ticked if I was planning on a 3G iPad. Though I’d rather they kept an unlimited plan as an expensive option, the new setup is kind of preferable to the semi-unlimited where it’s unlimited until it isn’t. At least the exact costs are laid out in the new structure. And it seems like AT&T is going to make it pretty easy to switch plans back-and-forth and even add tethering on a month-to-month basis.
Looking at my own usage, I seem to have never even approached the 200MB limit of the cheaper plan, which means the change might save me money.
Now definitely working on the style chapters that are listed in the current beta Table of Contents as “Fix Slow Tests”, “Help! My Test is Failing”, “Testing a Legacy Application”, “Testing Style and Structure”. These chapters are all currently kind of short, so they will probably be combined. The info from my Chicago Ruby talk the other day will be incorporated.
And since I haven’t put the link up in a few days, the book is still on sale.