+1 for exactly what james said (that's been my experience too). Faker is nice to have. Capistrano make my life a lot easier
Iain On 16 May 2012 11:42, Nicholas Faiz <[email protected]> wrote: > 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<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. > -- 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.
