Hello all, Could someone point to the current state of Dependency Injection in Rails, and current thinking? And, could you see a further state of inversion of control in Rails, where dependency injection is not just transparent to the programmer, but is handled while visually building an application, say by a software agent? As a user case scenario, a developer interacts with an agent with regards to an application she wants to build, and the agent, realising she will need a SOAP component, or lighttpd, or a blog controller and helpers, creates those (or resources them) and then presents the developer with a directory with the complete skeleton application? Any thoughts very welcome. I''m writing a report on LEGO-like webapp construction for the future, and its audience is not meant to be developers but senior educational institution managers (and some developers); so, the tone has to be more generic than deeply technical. Thanks in advance for any pointers, David -- David Plans Casal, Director of Research, Luminas Internet Applications Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: www.luminas.co.uk Orixo alliance: http://www.orixo.com/
DI has never really caught on in Ruby, though folks have made containers at various times. Dunno if this is good or bad. In a way, Rails does a lot of DI right now. Everything you need is plunked onto the Controller by default, instead of you looking it up, it is just a fairly fixed set of services at the moment, like J2EE =) -Brian On May 23, 2005, at 9:32 AM, David Casal wrote:> Hello all, > > Could someone point to the current state of Dependency Injection in > Rails, and current thinking? > > And, could you see a further state of inversion of control in > Rails, where dependency injection is not just transparent to the > programmer, but is handled while visually building an application, > say by a software agent? As a user case scenario, a developer > interacts with an agent with regards to an application she wants to > build, and the agent, realising she will need a SOAP component, or > lighttpd, or a blog controller and helpers, creates those (or > resources them) and then presents the developer with a directory > with the complete skeleton application? > > Any thoughts very welcome. I''m writing a report on LEGO-like webapp > construction for the future, and its audience is not meant to be > developers but senior educational institution managers (and some > developers); so, the tone has to be more generic than deeply > technical. > > Thanks in advance for any pointers, > > David > > -- > David Plans Casal, Director of Research, Luminas Internet Applications > Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 > Web: www.luminas.co.uk Orixo alliance: http://www.orixo.com/ > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > >
On May 23, 2005, at 7:32 AM, David Casal wrote:> Hello all, > > Could someone point to the current state of Dependency Injection in > Rails, and current thinking?Rails uses a form of dependency injection for accessing models, services, and helpers. Much of it is implicit, like most things in Rails. e.g. you simply reference the Post model and it is automatically loaded for you. This is a very simple form of DI--it doesn''t let you (for example) configure dependencies between multiple components--but it is certainly powerful enough for Rails. In fact, in the months that I''ve been working with Rails, I haven''t yet found anything that would be easier to do if Rails used a full-fledlged DI framework (like Needle or Copland). Thus, though I can''t speak for David, I suspect we''ve seen about as much of DI in Rails as we''re going to see. And I''m not too broken up about that, actually.> And, could you see a further state of inversion of control in > Rails, where dependency injection is not just transparent to the > programmer, but is handled while visually building an application, > say by a software agent? As a user case scenario, a developer > interacts with an agent with regards to an application she wants to > build, and the agent, realising she will need a SOAP component, or > lighttpd, or a blog controller and helpers, creates those (or > resources them) and then presents the developer with a directory > with the complete skeleton application?Hmmm. I''m not sure I see how your use case relates to dependency injection...? Perhaps I''m not understanding what you mean when you say DI. For what it''s worth, my experience has been that DI is primarily considered by people coming from Javaland, who had previously worked with frameworks like Spring, Picocontainer, or HiveMind. In Java''s environment, DI is a very viable solution to a number of sticky problems, but I posit that the dynamic nature of Ruby makes a full- blown DI framework of less value to Rubyists than it is to Java programmers. If you have a problem that you are considering using DI for (in Ruby), I''d be interested in hearing why you think it is necessary. (It may very well be--I''m just curious.) - Jamis
On 23 May 2005, at 15:21, Jamis Buck wrote:> On May 23, 2005, at 7:32 AM, David Casal wrote: > > Rails uses a form of dependency injection for accessing models, > services, and helpers. Much of it is implicit, like most things in > Rails. e.g. you simply reference the Post model and it is > automatically loaded for you.Right. I can understand this part ;-)> This is a very simple form of DI--it doesn''t let you (for example) > configure dependencies between multiple components--but it is > certainly powerful enough for Rails. In fact, in the months that I''ve > been working with Rails, I haven''t yet found anything that would be > easier to do if Rails used a full-fledlged DI framework (like Needle > or Copland).I see. This is why the discussion sort of petered out, then.>> And, could you see a further state of inversion of control in Rails, >> where dependency injection is not just transparent to the programmer, >> but is handled while visually building an application, say by a >> software agent? As a user case scenario, a developer interacts with >> an agent with regards to an application she wants to build, and the >> agent, realising she will need a SOAP component, or lighttpd, or a >> blog controller and helpers, creates those (or resources them) and >> then presents the developer with a directory with the complete >> skeleton application? > > Hmmm. I''m not sure I see how your use case relates to dependency > injection...? Perhaps I''m not understanding what you mean when you say > DI.I believe it''s my mistake. Using the wrong words. What I''m wondering is, given that Rails (inherently from Ruby) is already doing a great deal of DI on its own (and there follows a different ''philosophy'' than PicoContainer or Spring, I guess), where do you guys see it heading in terms of making it easier and easier for people to build web applications? It''s a very general question, I realise. What I''m after are, though, general thoughts on how you see concepts that enable people to implement ''less software'' principles to a point whereby they are writing almost -no- code, meaning, they are thinking about applications simply from the point of view of their -function-. Where do you think Rails will go next in that way? Cheers, David -- David Plans Casal, Director of Research, Luminas Internet Applications Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: www.luminas.co.uk Orixo alliance: http://www.orixo.com/
> Where do you think Rails will go next in that way?I concur with Jamis that Rails have seen the DI that it needs. In a lot of ways because DI is an approach to address problems that Ruby doesn''t feel much pain from. Unlike Java and other statics. DI is trading one form of programming (Java) for another form (XML configuration). I''m not sure that trade is particularly interesting in Ruby. I had one hard case I thought I needed DI for back around 0.9.5 of Rails. Injection of mocks deep into a hierarchy. We figured out how to do that in a no-code, no-configuration, convention-driven approach instead. That left us with zero pain to alleviate through DI. Thus, no DI needed. On top of that, DI is not an easy conceptual leap to make. Which makes it even less interesting for a framework that tries to cut down on conceptual as well as practical overhead. (This is not really Next Step, but just why DI isn''t it) -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails