But in my experience it’s a far cry from the type of boilerplate you have to deal with in Java. In my app we have over 100 controllers, and most of them are subtly different, and for good reason. Sure, we might be able to eliminate a few hundred lines of “boilerplate” by using one of these plugins, but it wouldn’t be any more readable because all the actions are pretty short anyway, and there wouldn’t be any valuable abstraction because there is no conceivable upgrade that we could apply to all the controllers without considering each of them individually anyway.

Now I can see the value in a specific project with a lot of resources that all have very similar semantic footprints. In that case you could define an app-specific default for handling resources. However I don’t believe most apps fall into this category. For most apps Rails provides a very nice set of primitives. The work in Rails 3 enhances these defaults, and I believe that many Rails developers have useful ideas that could be applied towards improving these primitives much as the Merb team did.

Yep, we need restfulcontextlogic! ;)

I like your plugins a lot (am using authlogic, searchlogic & settingslogic) and your post reflects exactly my thoughts when i tried these resource-helpers. Your post hardens my decision not to use such tools because of too much magic and obfuscation.

I like how you publish your thoughts and reflections! Your post made me feel good about leaving “magic restful helper tools” beside (although there might be special projects which could benefit from those tools).

The upcoming respond_to/respond_with in Rails 3 should also clean up some of the noise in Rails’ existing DSL.

There is nothing more annoying than looking back on your controller code and realizing 70% of your code has been the same since generating it 6 months ago.

So yes, I suggest using libraries cause it saves me from having to scan 50+ lines of code just to change 2. I’m all about maintainability. Fixing code due to upgrades is a fact of life no matter how simple your may be.

That’s what I like about these libraries, you can easily identify what has changed from convention. When I look at a “hand coded” controller, it’s a little harder to see what makes it unique from another controller. Where did it deviate from convention?

Personally, I feel you did have provide an amazing, innovative, and useful idea in resourcelogic. Contexts. For me, namespaces has been a big Fail. Too many files. Too many paths. Too many places to look to find the logic. You merged all this back into one place. Sweet. I hope this idea doesn’t die with resourcelogic.

I would throw in two more arguments: testing and test coverage, and upgrading to Rails 3.

At the end of the day it’s a matter of taste and personal experience. I’ll happily embrace new best practices once Rails 3 comes out, but for now I’m sticking with what supposedly is the intended use in Rails 2.