on the topic of resource controllers, here is a plugin that supports nested resources and has generators.
http://github.com/maxime/merb-simple-forms/tree/master Scott ekohe.com On Fri, Dec 19, 2008 at 12:01 AM, Tony Mann <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
