Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rethinking Rails 3 Controllers and Routes - PeepCode Blog

blog.peepcode.com

Post reply on HN
Print view View original

11–20 of 48 posts

Re: Rethinking Rails 3 Controllers and Routes - PeepCode Blog

#11

Post by mjw »

I think they should get rid of controllers and instead model RESTful / resource-oriented concepts like Resource and Entity directly!

A Resource is an object which responds to some subset of GET, PUT, POST and DELETE. It has a unique URL which identifies it.

(OK it's a bit more complicated than that, but you get the gist).

At present Controllers in Rails are a flat grab-bag of procedural code loosely associated with some group of resources, with meta-programming used to sweep some of the mess under the carpet. They're not an elegant way to model RESTful concepts.

(I actually have a framework in development for doing resource-oriented APIs on top of Rack, however it's currently very pre-1.0)

Re: Rethinking Rails 3 Controllers and Routes - PeepCode Blog

#13

Post by FlemishBeeCycle »

patio11 wrote: post #3

I think Rails developers seriously, seriously fetishize those six actions to the detriment of several other concerns. First, not everything your app will do is conveniently understandable in terms of resources, just like not everything code does is conveniently understandable in terms of operators. We have, thankfully, largely killed operator overloading and replaced it with functions. Why regress on function naming…

I've found that I rarely need additional actions outside of the canonical six, though I do firmly believe we need a 'delete' action analogous to 'new' and 'edit'. Sticking to those actions like DHH mentions, allows me to stop worrying about where something belongs and get things done. Considering that most apps are simply fancy CRUD guis over a db ... it works very well.

Routing is decoupled from those actions. You are not forced to use 'example.com/categories/1/cards/5', you can have (in this case) the #show action mapped to 'example/foo/some_card' if you want.

Re: Rethinking Rails 3 Controllers and Routes - PeepCode Blog

#14

Post by mjw »

mjw wrote: post #11

I think they should get rid of controllers and instead model RESTful / resource-oriented concepts like Resource and Entity directly! A Resource is an object which responds to some subset of GET, PUT, POST and DELETE. It has a unique URL which identifies it. (OK it's a bit more complicated than that, but you get the gist). At present Controllers in Rails are a flat grab-bag of procedural code loosely associated with s…

One particular thing which bothers me about controllers is the way they lump together obviously class- or collection-level methods (index, create, ...) with instance-level methods (show, update, delete, ...).

IMO requests should be routed to an instance representing a particular resource; the methods on that resource should correspond directly to the HTTP request methods. The collection (or the class) is a separate resource.

Re: Rethinking Rails 3 Controllers and Routes - PeepCode Blog

#15

Post by grandalf »

He's totally right. This is why I switched to Sinatra even for apps larger than the typical sinatra app.

Most of the need for the rewrite of the router came from the overhead associated with having all those (often unused) routes in memory.

My sinatra apps use very little memory and that is great for a lot of reasons.

I also realized that I don't like the rails convention of having a separate file for everything. Avoiding that has saved me lots of RSI.

Re: Rethinking Rails 3 Controllers and Routes - PeepCode Blog

#16

Post by papertiger »

dhh wrote: post #2

What an awesome way to advocate for code change. Very pretty. Unfortunately, I also think it's faulty. First, it doesn't actually advocate anything concrete. There's some hand-waving to Sinatra and other Rails features, but nothing concrete. If you're going to make such a pretty proposal, it should come with a call to specific action that people can get behind. This is double true when it comes to API design. It's al…

Well said. As soon as an application hits ~100 routes everyone would be writing their own routing layer just to be able to flexibly manage it all.

Convention born of common usage is a strength of Rails.

Re: Rethinking Rails 3 Controllers and Routes - PeepCode Blog

#17

Post by bphogan »

stanleydrew wrote: post #8
generalk wrote: post #6

Earlier quoted context omitted.

Everyone always says this, but I don't see it. I've seen non-technical users balk at long, confusing URLs, but I've never seen one of them praise or even remember a short, semantic URL. From the few non-technical people (mostly family) who I work with on a regular basis, URLs are just things to click on to get somewhere. Some of them are confusing. Having semantic, discoverable URLs is awesome for people that think i…

URLs have never been for users. Users don't care how your application works. They just want it to work. URLs are for developers. We have links to abstract away URLs for users. But that doesn't mean developers shouldn't think in terms of URLs. Users also don't care about database tables and data normalization, but that doesn't mean developers shouldn't.

A subset of users care about URLs when a hierarchy exists. I've seen it happen during usability testing. /projects/25/tasks shows the tasks list... and I've watched the user delete the end of the url to get to /projects.

Most users don't care, but there are advantages to a clean hierarchical URL scheme, and it's one reason I like how Rails does routing currently.

Re: Rethinking Rails 3 Controllers and Routes - PeepCode Blog

#18

Post by arohner »

stanleydrew wrote: post #5

I really like the part about getting back to thinking in URLs. The application is the URLs!

My sibling poster is dead on that 'normals' don't care about URLs. Often, I don't either. In my app, I have a bunch of "real" web pages, and then a bunch of "accidental" URLs that only exist to handle ajax requests. These aren't real pages, and what they return is of no value to the user unless they're on the page that generated the ajax call.

I don't want to go through the process of creating a new URL, figure out what its parameters will be, and then map those HTTP parameters to arguments to a server-side function. I want to magically link a client side action to a call on the server that may perform a side effect or return HTML, or both. The URLs are an implementation detail that I'd rather not think about.

Re: Rethinking Rails 3 Controllers and Routes - PeepCode Blog

#19

Post by stanleydrew »

arohner wrote: post #18
stanleydrew wrote: post #5

I really like the part about getting back to thinking in URLs. The application is the URLs!

My sibling poster is dead on that 'normals' don't care about URLs. Often, I don't either. In my app, I have a bunch of "real" web pages, and then a bunch of "accidental" URLs that only exist to handle ajax requests. These aren't real pages, and what they return is of no value to the user unless they're on the page that generated the ajax call. I don't want to go through the process of creating a new URL, figure out w…

If you care about REST (and arguably you should) then URLs are not an implementation detail. Especially if you are creating an API that others may eventually use to get at your data, URLs are everything. I'll say it again: the application is the URLs. Because ultimately the application is its resources and simple manipulations of them, which the URLs are representing.

Re: Rethinking Rails 3 Controllers and Routes - PeepCode Blog

#20

Post by cloudhead »

mjw wrote: post #11

I think they should get rid of controllers and instead model RESTful / resource-oriented concepts like Resource and Entity directly! A Resource is an object which responds to some subset of GET, PUT, POST and DELETE. It has a unique URL which identifies it. (OK it's a bit more complicated than that, but you get the gist). At present Controllers in Rails are a flat grab-bag of procedural code loosely associated with s…

This is really interesting, care to share more info?
Post reply on HN