Discontinuing Resourcelogic

Lately I’ve been really going back and forth between using tools like resourcelogic, inherited_resources, resource_controller, etc. And I gave each one of these libraries a more than fair shot. I’ve used all of them extensively, that’s the whole reason I created resourcelogic to begin with. I really liked resource_controller, so much that I decided to take it and kind of make my own version called resourcelogic. I ended up changing it quite a bit, and it worked out well, but it got out of hand. So I’m going to address why I advise against using libraries like this:

Deviating from standards makes it harder to work with other programmers

You have to think that certain things in rails are there for a reason. Rails is a result of thousands of programmer’s ideas, its used by extensively by programming teams large and small, and has tremendous success. There is a reason for that. Chances are, you aren’t going to sit around one day and come up with this idea that takes rails to the next level. I’m not trying to be a Debbie Downer and tell people not to try and improve rails or be innovative. That’s not the message I’m trying to send here. What I’m trying to say is that if you are sitting around and you come up with this crazy idea that deviates quite a bit from the rails standards, it’s probably wrong, even if you think it’s cool. I thought I did that with resourcelogic. I thought I was Mr. Awesome and I came up with this new development style for rails that was better than anything done before. I know that sounds pretty conceited but I was on my high horse. I thought the development style behind resourcelogic was awesome and I was going to share it with the rails community and people were going to eat it up.

So I ran with it, I developed an entire project with it by myself. Probably the most important project I’ve ever developed. I gave all of these libraries a more than fair shot. In the end, it made my project more confusing. The red flag was showing my code to another programmer. I had to explain what was going on and he was still kind of confused. Once he got it, he didn’t like it. This is not good. I didn’t like the thought of having to go through this with every programmer I was going to hire for this project. Which leads me to my next point:

You lose intent

This is probably my biggest complaint: you lose intent. There is a lot of code hidden away, so when you see small controllers with 4 – 5 lines of code providing all of this application specific functionality it kind of makes you wonder what is going on. There is no direct intent saying “this is what I’m doing”. There’s a lot of magic. My controllers looked like this:

create.before { ... }
create.wants.xml { ... }
create.wants.js { ... }
create.after { ... }
index.before { ... }

def my_own_custom_action
...
end

It just felt wrong. There is something refreshing about seeing this:

def create
  @user = User.new(params[:user])
  respond_to do |wants|
    if @user.save
      wants.html { redirect_to users_url }
      wants.js { render :inline => "window.location = '<%= users_url %>';" }
   else
     wants.html { render :action => :new }
     wants.js { ... }
   end
  end
end

Is that more code? Yes. Who said more code is bad when it makes more sense? I can look at the create method and know EXACTLY what is going on. I can add in some weird edge case if I need. I can do whatever the hell I want and I’m not confined to the standards set in resourcelogic. I don’t feel like I’m deviating from a pattern by doing that either. Sure, with resourcelogic you can write your own create method, but then I feel dirty, like I’m not following the pattern my application has defined.

Upgrading rails

What example would you feel more comfortable with if you were upgrading from rails 2 to 3? The one that uses a pattern that deviates from the rails standards, or one that uses the most basic of rails code? I would feel better with the second. That is standard rails code that I know for a 100% fact is going to be supported in Rails 3. Sure, you could up date the library in the first example to work with rails 3, but in my opinion thats a sign the library is messing with code it shouldn’t.

Conclusion

I’m not trying to knock libraries like resource_controller or inherited_resources, hell I wrote my own version called resourcelogic. So I would be knocking myself if I did. I just don’t think they are needed. Rails is simple to begin with. There is nothing wrong with writing out a full controller method. It’s simple, its direct, its clear, and it follows the rails standards. I can pick any programmer from the rails community and not have to say a word and they would understand a standard rails action. While at the same time I could show them a “resource controller” and a lot of people would wonder what the hell is going on. More importantly, edge cases feel clean. If a controller needs to do something a little bit different, that’s fine. I have full control of what is going on. I don’t have to use some weird API with before and after hooks to add in edge cases.

So the bottom line is that I am stopping support for resourcelogic. I will more than likely remove it from github because I don’t want to send people down the wrong path thinking its a good tool to use. For a simple project its probably fine, but in the end it’s just not worth it. All of the time and effort I spent writing resourcelogic and implementing it into my app was kind of a waste. With that time I could have made some major advancements and improvements to my application. But it’s things like this that make you a better programmer, you live and you learn. The lesson I learned is to not deviate from the rails standards too much. Use what they give you, chances are it will work out just fine because there are thousands of other programmers using the same tools to build a large variety of projects.

  • Share/Save/Bookmark


24 Responses to “Discontinuing Resourcelogic”

  1. laserlemon says:

    What’re you talking about? I _am_ gonna come up with the “new development style for rails that was better than anything done before.” :)

    Great post, plus I’ve worked with resourcelogic and it’s an awesome chunk of code! But I do agree that this kind of code can hide too much. I love the honesty regarding your own work. That’s refreshing. Keep up the good work!

  2. weepy says:

    Hey, I’ve been in a similar place to you and agree with much of what you’ve said.

    But what do you think of the new Rails 3 controller responders ? They won’t suffer from the standards problem, but perhaps some of your other points ?

  3. Joachim says:

    Great post, Ben.
    Doing, especially creating, something big and leaving it, is a hard one.
    Reflecting what’s going on in an honestly manner is difficult too.
    You did both and had the grandeur to tell the world.
    I appreciate that very much.
    Concerning the Rails specific part I totally agree with your conclusion – intent is an important attribute of a seasoned developer and loosing a considerable amount of it is just bad.

  4. Jeroen says:

    Great post, but I can’t agree with your end conclusion. I’m the first to admit that you shouldn’t go to crazy with clever tools/libraries. I’ve been down that path as well. It got me further with ruby in general, like in your case. I do think that controller abstractions are the way to go, unfortunately there is not yet an established standard.

    I began with make_resourceful, then resource_controller, even your resourcelogic and now inherited_resources. The latter one seems to solve all the problems I had with the previous ones. There is little magic, it is compliant with Rails standards (Rails 3 already) and it is very easy to apply edge cases. When you get the idea of controllers, it should be no problem for any rails programmer to get this tool. What you get back is a *lot* less code obviously. For a project with 20 controllers or more and only 5 percent edge cases this is a big win.

    Anyway, I’m curious what the general consensus is on this one.

    • grimen says:

      Agree! I had plenty of issues with the others, but inherited_resources is easy and maintainable. Newbies get it with a short intro.

  5. Jeremy says:

    I think that if you’re controller becomes a mass of custom blocks using one of these libraries then I can see your point.

    But I often find myself using these very little, and as projects go on removing them. When the controller is concise and they all do the same thing then these libraries are a great way to speed up development.

  6. I have to agree. I have used several of these resource libraries and even developed a solution of my own at one point, and while they’re great at removing a lot of boilerplate, it’s really difficult to go back after a while and read through your controllers and figure out what’s going on. It’s a case of being _too_ DRY, to the point of absurdity, utilizing AOP to the extreme by slicing what should be a straightforward create method into scattered slivers.

    I would suggest an alternative: use generators. Not only do they come with Rails, but they preempt the pain of writing generic resource actions yourself. And when you need to deviate from the norm, you can just edit the actions inline where such deviations can be read plainly in order by _any_ Rails developer. Generators give us most of the benefits of generic resource libraries without hurting readability.

  7. [...] Discontinuing Resourcelogic – I gotta say that I agree with the argument here about the perils of aggressively DRYing controllers by hiding their details in a plugin. [...]

  8. José Valim says:

    One of my grips with resourceful plugins are the way they provide to override default behaviors, as create.wants and so on. That’s why I created Inherited Resources, to reduce the amount of DSL needed and so you overwrite the actions inline. There is no before or after hooks, just reopen the method and call super.

    “If a controller needs to do something a little bit different, that’s fine.”

    Absolutely. It’s odd to add your custom methods if you have a lot of fancy DSL in the controller. Inherited Resources tries to stimulate you to overwrite methods. There is no problem if you can’t use any hook at all and need to overwrite the whole action.

    I think on Pareto principle on this. It should work good for 80% of controllers. I have no plans for the others 20% left.

    (This is obviously an attempt to bring you back to Inherited Resources. ;) I admit all your concerns are valid, but is my “job” to minimize them.)

    • benjohnson says:

      Hi Jose, I will say inherited_resources was the nicest one out of all of them. You did a great job making it flexible while also making it clean. I agree, using super and passing blocks to it, etc is much cleaner feeling and looking than using a custom DSL.

      What really brought this home for me was removing resourcelogic from my project. I was able to write all of the methods by hand in no time. It really wasn’t that big of a deal. I kept asking myself “why was I so against writing this code”? It seems like we are going through all of this effort to remove elementary code that I’m not sure is a bad thing. Yes, it’s a little redundant in area, but particularly in my project, from a big picture perspective, it wasn’t that redundant. I had quite a few controllers do things differently.

      I pulled out resourcelogic and rewrote the controller in my project in about a week. I probably spent more time than that trying to finagle certain controller to work cleanly with resourcelogic.

    • Dan Croak says:

      +1 inherited_resources is the only controller abstraction I’ve felt good about putting in a project.

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

  9. I still think make_resourceful is amazing. The library is simple enough that a quick look at the source will tell you everything you need to know. And the overrides still reveal intent.

    However, I am very excited for the new controller api changes in Rails 3.

  10. [...] I did not have time to study Inherited Resources or even to use it yet, but I suggest that you read the reasons why Ben Johnson decided to discontinue ResourceLogic development. [...]

  11. Mark Menard says:

    I agree with you whole heartedly. I was very skeptical of these libraries after briefly experiencing one. I’ve since removed the dependency on that code. It was an error. The loss of clean intention wasn’t worth it.

  12. Eric Davis says:

    It’s difficult to make the choice of stopping development on a project but it can be good for the community. I’ve used inherited_resources for my past three projects and it’s worked great. There is a learning curve but I think that curve will shrink once Rails 3 is out and in use.

    One suggestion: don’t remove the code from Github, it might be useful for people to read and understand how you did it. If anything, cripple it from running without modifying the source:

    # init.rb
    puts “***Do not run resourcelogic, it is no longer supported. Use ALTERNATIVE instead.***”
    exit(-1)

  13. That’s pretty much my experience as well, see related discussion at http://railsdog.com/blog/2009/07/resource-controller-for-skinny-rails-controllers/

    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.

  14. It sounds to me like a good portion of your pain can be alleviated by moderating your use of these libraries. If a controller has a lot of exceptions, don’t use resourcelogic. Write it out. But first, realize that this is a smell. Ask yourself why. Why is it so different from the norm? Does it need to 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.

    • Falk says:

      > Personally, I feel you did have provide an
      > amazing, innovative, and useful idea in
      > resourcelogic. Contexts

      Yep, we need restfulcontextlogic! ;)

  15. Jakub Suder says:

    I had the same experience while using the Hobo library in two projects. At first it seemed to make the work easier by automating everything, but in the end it turned out that it’s just as much work (or probably even more) than if I did it the standard way… It did make the code a bit shorter, but you had to spend a lot of time figuring out how to write it (I wrote about this here: http://psionides.jogger.pl/2008/12/02/code-like-a-hobo/ ).

  16. trans says:

    YADSL.

  17. Arik Jones says:

    I agree for the most part, but in practice it’s unreasonable for my needs to constantly worry about code I may never change later.

    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.

    • Falk says:

      Scanning 50 lines of well-written, good-structured (and maybe even documented) code is usually not a pain, but scanning 2 lines of super-magic can be really frustrating… So I vote for more lines and less magic.

  18. Falk says:

    Hi Ben,

    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).

  19. I mostly agree with your conclusions here. I think there is a bit of a bikeshed thing behind all these tools… every Rails app has controllers, and there is a lot of code that ends up looking pretty boilerplate.

    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.