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

21–30 of 48 posts

Re: Rethinking Rails 3 Controllers and Routes - PeepCode Blog

#21

Post by korch »

I have come to believe the only purpose of controllers is to impose a callback structure on top of a deterministic set of resource-models. The more simple and lean the better. CRUD just happens to be the most useful subset of callback structures, so it's the default. If you're putting code in your controller that isn't for one of the 7 resource actions, then it probably ain't controller code. (To be glib, you should instead move that code to lib/util.rb, the smartest next mistake).

On the flip side, if you remove all the non-REST code from your controller to the extreme, like what you'd see when using the inherited_resources gem, the only code left will be your callbacks. DHH said this presentation needed to show some code to make the claim hit home. So the only code left to remove is the callback code.

How could the controller callbacks be made better, and more invisibly integrate with the routing muck? Rails 3 is getting the state machine gem added to core, so no doubt about this time next year someone will have re-re-re-written the routing code using the state machine api. Could the routing muck be made to be the controller callbacks? I always liked the idea of how the Seaside framework did it using continuations, even though in practice it wasn't quite as good. Everyone knows that creating a zen-simple state machine api using continuations is not fun by anyone's measure of the word "fun."

Re: Rethinking Rails 3 Controllers and Routes - PeepCode Blog

#22

Post by blaix »

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…

I think it is advocating something concrete: Drop the separate routing layer. Then it gives two concrete examples of how to handle urls: Sinatra-style and HTTP-style methods in the controller. I think the biggest problem in the article is its use of an ugly url in the examples.

I actually like the HTTP-style method approach. You mention pushback to prevent people from creating mega-controllers, and I think this takes it even a step further. It really ties the controller to the resource. As mentioned in the article, this is already how the methods are called in the tests.

Re: Rethinking Rails 3 Controllers and Routes - PeepCode Blog

#23

Post by eob »

dhh wrote: post #10
h3h wrote: post #9

Earlier quoted context omitted.

A necessary component of mass production is consistency. Like it or not, Rails has reached the masses of web developers and enforces its constraints and conventions to facilitate the production of new web applications. I empathize greatly with DHH when he talks about large apps and the need for conventions. The truth is that most web developers will never devote as much attention to URLs as some people think they sho…

I'd be curious what hand-crafted URLs you feel aren't possible with the new Rails 3 router. We've gone far to allow all kinds of hand-crafted urls. For example, here's an example: get 'something/fun/:id', :to => "controller#action" You can map just about anything that falls outside of the conventions with a variety of that.

At that point, I suppose it is just a matter of taste: should the routes be specified inside each controller class, or should they be specified in a separate configuration file.

The over-engineer in me likes the way Rails 3 does it. That way I can pretend that my code is reusable, as the URL is decoupled from the code that eventually implements its handler.

But I suppose there is also something nice about a controller which self-defines the way in which it can be accessed.

Re: Rethinking Rails 3 Controllers and Routes - PeepCode Blog

#24

Post by dkubb »

mjw wrote: post #14
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 r…

Agreed. I always thought that Rails controllers violated the Single Responsibility Principle (http://en.wikipedia.org/wiki/Single_responsibility_principle) by mixing collection and member concerns into a single class.

Re: Rethinking Rails 3 Controllers and Routes - PeepCode Blog

#25

Post by blasdel »

stanleydrew wrote: post #19
arohner wrote: post #18

Earlier quoted context omitted.

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.

You simply do not understand REST. At all.

Caring about what URLs look like is at best irrelevant, but normally extremely counterproductive to actual RESTful implementation. If you're building URL strings to make requests (save for get-based forms) anywhere in any of your clients, you're doing it wrong. Wanking about pretty URLs just encourages you to go in the wrong direction.

In true REST, URLs are opaque identifiers. They might as well be UUIDs. The only way you're supposed to get one to request is in a response from the server.

Hypertext. Is. The. Engine. Of. Application. State.

Re: Rethinking Rails 3 Controllers and Routes - PeepCode Blog

#27

Post by derefr »

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…

> example.com/bingo-cards/holidays/halloween is superior in just about every conceivable way.

...ever A/B-tested that hypothesis? ;)

Re: Rethinking Rails 3 Controllers and Routes - PeepCode Blog

#28

Post by _pius »

eob wrote: post #23
dhh wrote: post #10

Earlier quoted context omitted.

I'd be curious what hand-crafted URLs you feel aren't possible with the new Rails 3 router. We've gone far to allow all kinds of hand-crafted urls. For example, here's an example: get 'something/fun/:id', :to => "controller#action" You can map just about anything that falls outside of the conventions with a variety of that.

At that point, I suppose it is just a matter of taste: should the routes be specified inside each controller class, or should they be specified in a separate configuration file. The over-engineer in me likes the way Rails 3 does it. That way I can pretend that my code is reusable, as the URL is decoupled from the code that eventually implements its handler. But I suppose there is also something nice about a controlle…

The over-engineer in me likes the way Rails 3 does it. That way I can pretend that my code is reusable, as the URL is decoupled from the code that eventually implements its handler.

You don't have to pretend ... it actually is reusable. I don't get what's "over-engineer"ed about it.

Re: Rethinking Rails 3 Controllers and Routes - PeepCode Blog

#29

Post by edwincheese »

This suggestion is good until you need to change the whole set of URLs. Of course in a single web site deployment you seldom want to change URLs (and it is often a bad idea), but I changed URL scheme sometimes when I need to deploy my application in another place and integrating with other system. (e.g. Changing from path routing to subdomain). I would made crazy if I need to modify every controller to change the URL scheme.

I think the routing abstraction is necessary and useful in larger application. Isn't it a very simple and clever syntax for the routing configuration is good enough?

Re: Rethinking Rails 3 Controllers and Routes - PeepCode Blog

#30

Post by psadauskas »

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…

I've been thinking about this very thing for awhile, too. I wrote some code to demonstrate how I think resource/routes/controllers should work: https://gist.github.com/d64847016687e82d104b

Started on an implementation based on Rails 3 ActionPack, but never got very far. To make the case statements work, you have to override #=== on Symbol.

Post reply on HN