Hi, This is becoming amusing. :) I almost replied to James' post to disagree. In the interest of defending IR I'll just make a quick response.
Everything in IR is configurable. The argument, for e.g., that it's bad because it configures destroy methods on your controllers is only a statement that IR is bad for programmers who don't know how to use the tool properly, specifically a statement like: actions :all, :except => [ :destroy ] To say that this configuration is risky is somewhat similar saying that it's foolish to use the resources helper in routes, e.g.( resources @foo ) because you might forget to exclude certain routes. So yeh, I really can't see the problem with IR generally. It's quite a good lib.. The further issues touched upon like extending its workflow have never been an issue for me. It's object creation lifecycles are easy to wrap around (create!, update!, etc.) and it's easy to place appropriate filters to control how it builds its data. I generally start out by letting all of my controllers use it, then refine actions as I need to. There are some situations where it's easier to just not use IR, but for most things it's a great quick start. Cheers! Nicholas On Wednesday, May 16, 2012 10:47:17 AM UTC+10, ben_h wrote: > > 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 view this discussion on the web visit https://groups.google.com/d/msg/rails-oceania/-/rIdN-3vEei4J. 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.
