Comments on: New Flash Community Developments: Robotlegs and Signals http://blog.nobien.net/2009/12/14/new-flash-community-developments-robotlegs-and-signals/ A nerd blog about nerdy things by ... nerdy guys? Tue, 11 Oct 2011 21:59:52 +0000 hourly 1 http://wordpress.org/?v=3.0.3 By: Matt http://blog.nobien.net/2009/12/14/new-flash-community-developments-robotlegs-and-signals/comment-page-1/#comment-4575 Matt Sun, 03 Jan 2010 16:24:00 +0000 http://blog.nobien.net/?p=178#comment-4575 I've been fiddling around with it lately and its really growing on me. Being in the industry that I'm in, I tend to compile with the Flash IDE, but I've started using ANT and MXMLC and really starting to like it. The magic is pretty sweet, so much so that I'm considering changing my workflow. What I'm really curious about now is modular application development so I'm looking into Till's beta version of SwiftSuspenders that supports child injectors. The idea of a context inheriting mapping rules sounds really cool. I’ve been fiddling around with it lately and its really growing on me. Being in the industry that I’m in, I tend to compile with the Flash IDE, but I’ve started using ANT and MXMLC and really starting to like it. The magic is pretty sweet, so much so that I’m considering changing my workflow. What I’m really curious about now is modular application development so I’m looking into Till’s beta version of SwiftSuspenders that supports child injectors. The idea of a context inheriting mapping rules sounds really cool.

]]> By: Joel Hooks http://blog.nobien.net/2009/12/14/new-flash-community-developments-robotlegs-and-signals/comment-page-1/#comment-4574 Joel Hooks Sun, 03 Jan 2010 15:34:06 +0000 http://blog.nobien.net/?p=178#comment-4574 Hi Matt, The automatic metadata Dependency Injection might be better thought of as helper robots doing tedious repetitive work behind the scene. You could forgo the automagic help that is going on and manually inject your dependencies, but that is boring and un-fun. In that sense, the automation certainly is "magical" in that it frees us up to concentrate on the more important aspects of our systems. I'm really looking forward to the implementations that start to crop up this year. That is the most exciting aspect of Robotlegs in my opinion. It is a "framework framework" of sorts that will allow people to implement interesting workflows. Hi Matt,

The automatic metadata Dependency Injection might be better thought of as helper robots doing tedious repetitive work behind the scene. You could forgo the automagic help that is going on and manually inject your dependencies, but that is boring and un-fun. In that sense, the automation certainly is “magical” in that it frees us up to concentrate on the more important aspects of our systems.

I’m really looking forward to the implementations that start to crop up this year. That is the most exciting aspect of Robotlegs in my opinion. It is a “framework framework” of sorts that will allow people to implement interesting workflows.

]]> By: Matt http://blog.nobien.net/2009/12/14/new-flash-community-developments-robotlegs-and-signals/comment-page-1/#comment-4527 Matt Tue, 15 Dec 2009 04:12:10 +0000 http://blog.nobien.net/?p=178#comment-4527 Really appreciate your comment, Till. I haven't given up on Robotlegs or DI at all. Robotlegs and SwiftSuspenders are clearly great tools for developing applications in a decoupled manner, which I really wish I was doing more of. Perhaps part of my apprehension is due to the particular sector of the Flash development industry that I'm in. As mentioned, I've had succuss using PureMVC on projects before, but that was when I was the only developer and it ended up being more of an exercise in applying what I had learned with my own experiments. Lately I've been fantasizing about getting the developers I work with into working in a similar, predictable manner. My instincts tell me that it would be best to adopt a standard architecture such as Robotlegs. However, developers in the advertising/marketing sector tend to not really be into frameworks such as Robotlegs or PureMVC. So my next step is to investigate creating my own framework using Robotlegs that would be structured in a way that would perhaps be a bit easier to use for my co-developers. I'm definitely lurking the discussion forums and perhaps you'll see me join in at some point. Until then, I'm going to experiment some more with it all and see what I can come up with. Really appreciate your comment, Till. I haven’t given up on Robotlegs or DI at all. Robotlegs and SwiftSuspenders are clearly great tools for developing applications in a decoupled manner, which I really wish I was doing more of. Perhaps part of my apprehension is due to the particular sector of the Flash development industry that I’m in. As mentioned, I’ve had succuss using PureMVC on projects before, but that was when I was the only developer and it ended up being more of an exercise in applying what I had learned with my own experiments. Lately I’ve been fantasizing about getting the developers I work with into working in a similar, predictable manner. My instincts tell me that it would be best to adopt a standard architecture such as Robotlegs. However, developers in the advertising/marketing sector tend to not really be into frameworks such as Robotlegs or PureMVC. So my next step is to investigate creating my own framework using Robotlegs that would be structured in a way that would perhaps be a bit easier to use for my co-developers. I’m definitely lurking the discussion forums and perhaps you’ll see me join in at some point. Until then, I’m going to experiment some more with it all and see what I can come up with.

]]> By: Till Schneidereit http://blog.nobien.net/2009/12/14/new-flash-community-developments-robotlegs-and-signals/comment-page-1/#comment-4526 Till Schneidereit Mon, 14 Dec 2009 23:29:07 +0000 http://blog.nobien.net/?p=178#comment-4526 Hey Matt, thanks for the overview of RL and Signals! In my experience with both learning the concepts of automated DI and explaining them to others, the main problem seemed to stem from trying to understand more than there actually is to understand. Automated DI solutions such as SwiftSuspenders do exactly two things: - They store various types of request-response-mappings the application developer provides - They inspect (again: application developer provided) objects to find injection points declared on them and set their values in accordance with the mappings A slight complication of things is that they do these recursively. I.e., when injecting a value, they inspect it for injection points and apply the mappings to them as well. But that's really it. Robotlegs adds another layer by providing a mechanism that basically allows you to say: "when a view of this type gets added to the display list, create an instance of that type (the mediator) and perform DI on it. When the view gets removed from the display list, remove the mediator instance as well." Here, the slight further complication is that Robotlegs adds a temporary mapping (using Injector#mapValue) for the view instance to the injector, allowing the mediator to receive a reference to it in a strongly typed manner. But again, (apart from additional features and other possible ways of working with Robotlegs) that's really it. In my view, Robotlegs doesn't do anything particularly spectacular in and of itself. What makes it so awesome is how effortless it makes the things it does seem. I guess that's where the "magic" part comes in: One always expects there to be more than meets the eyes, because it seems unrealistic that so (conceptually) little does so much. So, if you haven't completely given up on Robotlegs and DI, feel free to join the Robotlegs mailing list and discuss anything that we're not doing a good job of explaining right now. cheers, till Hey Matt,

thanks for the overview of RL and Signals!

In my experience with both learning the concepts of automated DI and explaining them to others, the main problem seemed to stem from trying to understand more than there actually is to understand.

Automated DI solutions such as SwiftSuspenders do exactly two things:
- They store various types of request-response-mappings the application developer provides
- They inspect (again: application developer provided) objects to find injection points declared on them and set their values in accordance with the mappings

A slight complication of things is that they do these recursively. I.e., when injecting a value, they inspect it for injection points and apply the mappings to them as well.

But that’s really it.

Robotlegs adds another layer by providing a mechanism that basically allows you to say:

“when a view of this type gets added to the display list, create an instance of that type (the mediator) and perform DI on it. When the view gets removed from the display list, remove the mediator instance as well.”

Here, the slight further complication is that Robotlegs adds a temporary mapping (using Injector#mapValue) for the view instance to the injector, allowing the mediator to receive a reference to it in a strongly typed manner.

But again, (apart from additional features and other possible ways of working with Robotlegs) that’s really it.

In my view, Robotlegs doesn’t do anything particularly spectacular in and of itself. What makes it so awesome is how effortless it makes the things it does seem.

I guess that’s where the “magic” part comes in: One always expects there to be more than meets the eyes, because it seems unrealistic that so (conceptually) little does so much.

So, if you haven’t completely given up on Robotlegs and DI, feel free to join the Robotlegs mailing list and discuss anything that we’re not doing a good job of explaining right now.

cheers,
till

]]>