Hi Shaun,
I've crossposted this to the SmartyPants google group, hope that's no problem :)
When I've had to do things like that in the past, I simply use a named live injection. Say for example I have a sessionId String that several services need to know about. I'd have this in anything that needs it:
[Inject(live, name="sessionId")]
public var sessionId : String;
And there are a couple of ways to set up the rules for something like that.
1) You can not set up the rule until you actually have the value. Say from your login process:
function loginResult(sessionId : String) : void
{
SmartyPants.whenAskedFor(String).named("sessionId").useInstance(sessionId);
}
This will then go and "re-inject" any injection points that have been marked as "live". Consider it the same as Flex Bindings.
2) You can create an "App model" class that holds things that might have been globals in the past:
[Singleton]
[Bindable]
public class ApplicationModel
{
public var someField : SomeClass;
public var sessionId : String;
}
then simply inject the ApplictionModel into anything that needs it.
If you're after something a little more powerful, such as "sessionId should be 7 when injected into a property of A, and it should be 12 when injected into a property of B", that's what's known as the "robot legs" problem. The SmartyPants solution for that exists in my head, but I want to get 1.0 out the door before I start on it for 1.1
The docs are pretty out-of-date at the moment. There's nothing incorrect in them, but they're just missing a few things. It's on the list to be done for 1.0 once the code changes are frozen.
-Josh
On Wed, Feb 18, 2009 at 9:45 PM, Shaun Smith
<sh...@boyblack.co.za> wrote:
Hello Josh,
My name's Shaun, I dropped a (long winded!) comment on your blog regarding some ideas I have for a little DI MVC framework. I imagine that Smartypants-IOC would be able to take care of most of it - once I've figured out how to use it - but there is one aspect that I'm not sure it would be able to handle: cascading properties (for lack of a better term). I've put together a little project to explain what I mean by that (attached).
What it does:
Configures a Mediator Factory that maps Mediator classes to view classes.
Listens for ADDED_TO_STAGE or CREATION_COMPLETE events, constructs a Mediator for a view component, sets a reference to the view on the Mediator, and injects some properties into that Mediator.
Certain properties get looked-up by traversing the display list, from the view component to the root, looking for view components that have Mediators with marked properties of the same name (this should include type checking, but doesn't at the moment).
So, there is a component called SomeList and a Mediator called SomeListMediator. No matter how deeply nested, whenever a SomeList component arrives on the display list, a SomeListMediator will be created for it. Some properties get injected into SomeListMediator, but one (userId) is marked as "resolveable" (bad word, should be "cascading" or something like that). The factory traverses the display list and finds a value on another Mediator to inject into it. In this case it finds userId in the PopWindowMediator.
It works, but the MediatorFactory code is ugly - I'm a n00b! Ideally Smartypants-IOC could take care of all the dependency injection, but could it somehow do the cascading property thing?
I look forward to hearing your thoughts. Any advice on how I might use Smartypants (even RTFM!) to achieve any of the above functionality would be greatly appreciated.
Many thanks!
Best Regards,
Shaun
Shaun Smith
+27 72 118 7631
sh...@boyblack.co.za
http://www.boyblack.co.za/
http://shaun.boyblack.co.za/
--
"Therefore, send not to know For whom the bell tolls. It tolls for thee."
Josh 'G-Funk' McDonald
-
jo...@joshmcdonald.info
-
http://twitter.com/sophistifunk -
http://flex.joshmcdonald.info/