[eob]

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.

[_pius]

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.

[dkubb]

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.

[mikek85]

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.

[binspace]

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.