12 ms·

Why You Shouldn't Use Rails' Scaffolded Controllers

6 points by r00k 16y ago

rhizome 16y ago
There is nothing in the post to indicate that the InheritedResources gem is any more state of the art than standard scaffold controllers (which very few if any users leave without modifications, contrary to the implication of the article). It does seem to be replacing some implementation details with magic in the pursuit of DRY, which is left unmentioned and invisible in the post, but I don't see what advantage this has over the common technique of using a before_filter that sets up commonly used variables and such. The fact that the author uses dateless posts and comments (SEO) does not add to its credibility for me, but user-hostile design sticks out like a sore thumb for me so that could just be my own peccadillo.
- r00k 16y ago
  Hi there! I'm the author. Thanks for your feedback. > "There is nothing in the post to indicate that the InheritedResources gem is any more state of the art than standard scaffold controllers" I think you may have missed my point (which, as the author, is probably my fault) :) It's not that inherited_resources controllers do anything better than the standard controllers. It's that each controller does exactly the same thing, but one is 81 lines shorter. > "The fact that the author uses dateless posts and comments (SEO) does not add to its credibility for me" There are dates on each post (check the top left). Also, you say credibility goes down because I have comments (which you seem to think are for SEO purposes)? I'm afraid I don't follow at all.
  - rhizome 16y ago
    Ah, it's a design element. I actually remember looking at that area and noticing the stitching and that the border looked nice, but to be honest my brain only saw a Levi's tag hanging there (it didn't look like a date). Also, there is no year. Anyway, mea culpa, I'll look harder next time. Sure, it's 81 lines shorter, but I don't know what's going on there, either. Its one thing to express a method in an elegant fashion, but an entirely different thing to hide it off someplace, which is how I read what is happening here. I'm guessing there are some instance variables available afterwards? Plus, it's an additional dependency. And yeah, I read the title "Why You Shouldn't Use Rails' Scaffolded Controllers" and "...the state of the art has moved on" to mean that what you were talking about was supposed to be better.
    - r00k 16y ago
      Yeah, fair enough, the date is a bit easy to miss. Not my favorite aspect of the theme I'm using. Sure, it's 81 lines shorter, but I don't know what's going on there, either. Sure, but I'd imagine most developers have the default controller actions memorized by now (I do). So, this class you're inheriting from does exactly what you're used to. Only now, you don't have repeated controller code and functional tests everywhere. Really, this is an application of the DRY principle to app/controllers.

6 points by r00k 16y ago

There is nothing in the post to indicate that the InheritedResources gem is any more state of the art than standard scaffold controllers (which very few if any users leave without modifications, contrary to the implication of the article). It does seem to be replacing some implementation details with magic in the pursuit of DRY, which is left unmentioned and invisible in the post, but I don't see what advantage this has over the common technique of using a before_filter that sets up commonly used variables and such. The fact that the author uses dateless posts and comments (SEO) does not add to its credibility for me, but user-hostile design sticks out like a sore thumb for me so that could just be my own peccadillo.

r00k 16y ago
Hi there! I'm the author. Thanks for your feedback. > "There is nothing in the post to indicate that the InheritedResources gem is any more state of the art than standard scaffold controllers" I think you may have missed my point (which, as the author, is probably my fault) :) It's not that inherited_resources controllers do anything better than the standard controllers. It's that each controller does exactly the same thing, but one is 81 lines shorter. > "The fact that the author uses dateless posts and comments (SEO) does not add to its credibility for me" There are dates on each post (check the top left). Also, you say credibility goes down because I have comments (which you seem to think are for SEO purposes)? I'm afraid I don't follow at all.
- rhizome 16y ago
  Ah, it's a design element. I actually remember looking at that area and noticing the stitching and that the border looked nice, but to be honest my brain only saw a Levi's tag hanging there (it didn't look like a date). Also, there is no year. Anyway, mea culpa, I'll look harder next time. Sure, it's 81 lines shorter, but I don't know what's going on there, either. Its one thing to express a method in an elegant fashion, but an entirely different thing to hide it off someplace, which is how I read what is happening here. I'm guessing there are some instance variables available afterwards? Plus, it's an additional dependency. And yeah, I read the title "Why You Shouldn't Use Rails' Scaffolded Controllers" and "...the state of the art has moved on" to mean that what you were talking about was supposed to be better.
  - r00k 16y ago
    Yeah, fair enough, the date is a bit easy to miss. Not my favorite aspect of the theme I'm using. Sure, it's 81 lines shorter, but I don't know what's going on there, either. Sure, but I'd imagine most developers have the default controller actions memorized by now (I do). So, this class you're inheriting from does exactly what you're used to. Only now, you don't have repeated controller code and functional tests everywhere. Really, this is an application of the DRY principle to app/controllers.