Comment by h3h | Hacker News Reader

Comment by h3h | Hacker News Reader

Parent Full thread

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 should. Full stop.

With that in mind, stable conventions are of paramount importance if Rails is going to maintain its practicality when building large web applications. On the spectrum of poor conventions to good ones, Rails has been much closer to the idealistic end of pushing REST principles and the concept of resources over haphazard URLs and actions. We owe a debt to Rails and its designers for the abundance of REST in production today.

That said, I empathize infinitely with Adrian Holovaty. I love URLs and I want them to always be beautiful everywhere. It's true that Rails gives less obvious control over URLs than Django or Sinatra, but it does so for the reasons mentioned above. There are probably small changes that could be made to make Rails more URL-aware for those of us who would like to craft every URL with loving adoration, but those changes absolutely must be compatible with the consistency already embodied in the Rails routing system. I haven't thought much about what those changes might look like, but I agree with DHH that the post above feels very hand-wavy in the proposal department.

Just remember that we URLophiles are a minority. Rails must work well for the majority and they will never care about URLs.

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.

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.

I don't understand how a monolithic route mapping layer & a separate resource layer is more reusable than a modular resource + route layer. Care to explain?

I find the Sinatra approach leads to less code and less complexity, especially for larger apps. This is because it is easy to extract middleware using Sinatra, since I break up separate resources anyways, instead of the single Application object.

Whenever I've tried to reuse the same controller for two URLs, I usually end up with some conditional logic within the controller to handle difference in parameters available from the URL.

I think a better approach would've been for me to subclass one from the other, or have a common parent class, and then handle the parameter differences within each subclass. At that point you'd end up with a 1:1 mapping between controller class and URL anyway.

That 1:1 mapping is a good thing, but I don't think that's a reason to completely do-away with routing altogether. Sticking the route in the controller just makes the code harder to follow.

Reply on news.ycombinator.com