Hi all. I just whipped up a little ResourceController of my own:
http://pastie.org/342344 Using this, most of my controllers now look like this: def Companies < ResourceController end This is very cool. Martin, thanks for the inspiration! Some notes: * handles nested resources that are one level deep * supports pagination if you have the will_paginate gem. * uses naming conventions to do its magic, and creates the instance variables you would expect, so the views can get at them * if you need to change an action, just override its method, and use the protected methods to set things up * to hide an action, use the hide_action class method Let me know ways that you think the code could be improved. Then we can figure out whether something like this should be baked into Merb. ..tony.. On Wed, Dec 17, 2008 at 6:11 PM, Martin Gamsjaeger <[email protected]>wrote: > > @Tony > > I can see where you're coming from concerning all the methods for > overriding different aspects of each action. At first I wasn't too > happy with having so many methods inside the controller namespace, but > then I decided to go that way because it's easy to customize it this > way since all you need to do is to override a method. It's "extract > method all the way down". All other options I could come up with > (lambdas and/or class/instance_eval) made it harder to access > controller internals (ivars, content_type, display, redirect, render) > because they would all need more dsl'ish syntax on the ResourceProxy > (or on the controller itself) and thus would need to move things > (controller internals) around quite a bit. > > @Tony and Michael > > That said, I consider this implementation rather "unmagical". All the > controller methods are basically the result of the "extract method" > pattern applied to the too many "identical" (mostly rails but merb > catching up fast) controllers I've already written. There is no > metaprogramming, only one class method entry point, including of > modules, overwriting of methods and following a simple naming > convention (only in the case of providing different content types). I > definitely don't want to be picky! I just want to explain it :) > > Of course! merb_resource_controller cannot handle all kinds of > resources, but probably quite a large subset. I tend to give my models > (orm or not) the same CRUD interface that datamapper provides. Up till > now I could always come up with a domain resource that matched the > CRUD pattern nicely and fitted nicely into the application domain > (most of the time making it even clearer). As I said, sometimes these > are not directly database backed models, but aggregates of these > (multimodel forms) or simple POROs. > > The *one thing* I really like about merb_resource_controller is that > it cuts down repetitive (thus in my experience copy/paste errorprone) > controller code from 60 (without xml/json api) to roughly 5 (with > xml/json api) descriptive lines. This means I have less code to > maintain and more API for my app. That's a good thing! > > Only thing I'm not sure is how to go about request specs. I thoroughly > tested merb_resource_controller itself and I now have the feeling that > writing request specs for all the merb_resource_controllers is somehow > useless !?! What I really want to test is if I have the right routes > setup and if they lead to the right resource representation. But > really, as I'm writing this I remembered Michael's comments on > cucumber. I should really give that a try I guess? > > What's left to say is that I somehow feel sorry about hijacking this > thread! It's just that I got excited because I committed the new > content type features only minutes before reading this thread and the > word DRY/dry/drying inevitably alerts me :-) > > Anyways, I'm off for a short skiing holiday over the weekend. Enjoy yours! > > cheers > snusnu > > On Thu, Dec 18, 2008 at 02:07, Michael Klishin > <[email protected]> wrote: > > > > > > On 18.12.2008, at 3:36, Tony Mann wrote: > > > >> The problem is that you have to explicitly declare the finders. I > >> was imagining something even more automated, where calling an > >> automagic #foo method would go into params, find the appropriate id, > >> and do a Foo.get. Furthemore, an #parent method would get the > >> resource parent, if there is one, and a #resource method would get > >> the resource instance that the controller is managing, if there is > >> one. > > > > > > This is just to show that it is not a lot of work to cook something > > like this. I personally do not use plugins like resource controller, > > but if you want automagic behavior, resource_controller and friends > > will be useful for you. This area has been explored for a few years > > now in the Ruby community, and I guess plugin authors already borrowed > > all the goodies from each other :) > > > > MK > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "merb" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/merb?hl=en -~----------~----~----~----~------~----~------~--~---
