On 15/05/2012, at 10:27 PM, James Healy wrote: > On 15 May 2012 17:23, Nicholas Faiz <[email protected]> wrote: >> Inherited Resources. It's great. > > Personally I avoid inherited resources and devise like the plague. > They're helpful for the simple case, but as soon as you start > overriding the defaults you end up with control flow that's impossible > to understand.
Totally agree. I think the idea behind inherited_resources is laudable -- the less repetition, the better -- and I've used it a fair bit in the past. But I've come to realise that while the idea is sound, the implementation isn't, for the reasons James gave. A real-world controller (i.e. with a couple of customisations) backed onto inherited_resources is too surprising to work with reliably. It's less bad than using before_filter because the overrides are exposed methods within inherited_resources' implementation of the action, and so will appear in the callstack. But it still violates the principle of least surprise. Anyhow, I really like: * rein -- A great set of helpers to add DB-level constraints within migrations. Written by Josh Bassett. * sequel -- A very capable ORM, that in particular supports a lot of postgres' advanced features, but is also fantastic for quick, lightweight DB stuff from ruby-land (particularly from a sinatra app). * ir_b -- What I use instead of ruby-debug: it drops you in a repl at the current binding, and it's about 70 lines of code, with no dependencies. In fact, it's worth checking out the code: it's a good lesson about how bindings in ruby work. https://github.com/jugyo/ir_b/blob/master/lib/ir_b.rb - Ben -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" 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/rails-oceania?hl=en.
