@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 -~----------~----~----~----~------~----~------~--~---
