[deleted]
Rethinking Rails 3 Controllers and Routes - PeepCode Blog
31–40 of 48 posts
Re: Rethinking Rails 3 Controllers and Routes - PeepCode Blog
#32Slightly off-topic: It annoys me when I have to scroll both up and down while reading an article to read it sequentially (see Idea 1 and Idea 2 for an example infringement).
You didn't enjoy the benefit of being able to compare the two ideas side-by-side? They both neatly fit the screen in most resolutions if your browser window is max height, no scrolling in that particular case.
Beautifully designed article and your specific example is a great attention to detail on the author's behalf.
Re: Rethinking Rails 3 Controllers and Routes - PeepCode Blog
#33What 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.
This applies even with Rails routes. Our routing scheme does not match that of Rails (we want seo friendly routes, that does not always fit the /collection-name/:collection_id paradigm).
I think simple routing systems, like Sinatra, are the way to go here.
From a simple library that does not get in the way, it's not too difficult to come up with a convention that matches your needs. The overall application then becomes simpler because I don't have to fight a heavy-weight routing system that misses the point.
Re: Rethinking Rails 3 Controllers and Routes - PeepCode Blog
#34Earlier quoted context omitted.
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 identifi…
This is unnecessarily personal and offensive. Note that I never said URLs must be pretty.
Re: Rethinking Rails 3 Controllers and Routes - PeepCode Blog
#35He'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. Avo…
Conventions are powerful. Programmers should be allowed and able to come up with their own conventions that match their domain.
I personally find sinatra routes more scalable than Rails routes because they are modular (defined within the resources). Rails routes are one monolithic file with a separate controller layer.
Re: Rethinking Rails 3 Controllers and Routes - PeepCode Blog
#36Earlier quoted context omitted.
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.
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.
Re: Rethinking Rails 3 Controllers and Routes - PeepCode Blog
#37I agree.
I was introduced to Ruby through Sinatra. Developed all my web apps using that though I used to play around with Rails. I had an initial idea that Sinatra was meant for small apps, and for anything serious you should go Rails.
However that idea seems invalid now; the way I'm now used to Sinatra, it is kind of getting almost all the goodies of Rails without the Routing layer (which I find hard to follow - as mentioned by the OP).
Sinatra+ActiveRecord+ActionSupport+ActionView = Rails - Routing - ActionController
Re: Rethinking Rails 3 Controllers and Routes - PeepCode Blog
#38Earlier quoted context omitted.
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.
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.
Re: Rethinking Rails 3 Controllers and Routes - PeepCode Blog
#39What 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…
The main argument is flexibility and acknowledging what the role of the controller actually is in a resource-oriented application
Idea 2 is the way to go because it's resource oriented and you get useful stuff like 405's for free which you don't with the sinatra approach.
Please don't remove routing. Having routes is important - it makes the code more descriptive and easier to follow. All a route needs to do is map one URI pattern to one controller, i.e:
/blog -> BlogController
/blog/:post -> BlogPostController
/blog/:post/comments -> BlogPostCommentsController
I wrote a hack for Zend Framework last year to prove how this would work:
http://restafari.blogspot.com/2010/04/restful-php-applicatio...
Re: Rethinking Rails 3 Controllers and Routes - PeepCode Blog
#40Slightly off-topic: It annoys me when I have to scroll both up and down while reading an article to read it sequentially (see Idea 1 and Idea 2 for an example infringement).
You didn't enjoy the benefit of being able to compare the two ideas side-by-side? They both neatly fit the screen in most resolutions if your browser window is max height, no scrolling in that particular case. Beautifully designed article and your specific example is a great attention to detail on the author's behalf.
Three things: 1) I (and other people) like to scroll the page as we read so our eyes stay in a relatively fixed position and the text moves under it. 2) Plenty of monitors can't fit those entire sections. 3) Those two sections didn't benefit much (if at all) from side-by-side comparison.