I love Lightwire for dependency injection, it’s lightweight, it’s not XML based, and allows for mixins which saves me from having to constantly add constructor properties or setters. However, I was recently confronted with a problem. When using Lightwire for transient beans, I often found myself wanting to inject dependencies, but also pass in some properties/dependencies at runtime (for example, some data somebody entered in a form). Now, an obvious way to do this would be to define the bean without that dependency, create a setter for it, and then add whatever you need to the bean using that. Somehow, it felt like kind of a roundabout way of doing it, so I figured I’d look for a way to be able to do it at the time of bean invocation. In terms of code, here’s what I was looking for:
myBean = application.lightwire.getBean("myBean", form.runTimeData, form.moreData);
INSTEAD OF
myBean = application.lightwire.getBean("myBean");
myBean.setRuntimeData(form.runTimeData);
myBean.setMoreData(form.moreData);
Note that you could also do the above with one setter that would set all the runtime data you want at once. Still, it’s an extra call, and that just bothers me to no end! So after some modifications to the Lightwire code I was almost able to do what I wanted, with a small caveat. I wasn’t able to use numbered arguments, had to settle for named arguments for now (though I’m still working on it). So right now I’m able to do this:
myBean = application.lightwire.getBean( objectName="myBean", runTimeData=form.runTimeData, moreData=form.moreData );
I’m not 100% happy with it because I’d like to get it working with numbered argument and avoid all that typing, but the arguments/argumentCollection object is a weird one and I haven’t been able to swing that yet. Hoping I’ll come up with some sort of solution eventually (if anybody has some insights in the Java internals of argumentCollection and how to manipulate that, I’m all ears). But for now this works for me.
I’m interested in knowing if anybody else would find this feature useful, or if for any reason this would be bad practice and maybe I’m going about things all wrong. Again, I know it’s kind of a small nitpicky thing, but when you’re coding all day, small details make a big difference!


March 8th, 2010 at 2:05 pm
[...] blogged about supporting “arbitrary runtime constructors” in LightWire. Check out his posting and comment at the bottom as to whether you like or dislike the idea. If it’s popular enough [...]
March 8th, 2010 at 4:20 pm
Could be handy, maybe just have a second “populate” argument to the getBean method where you can pass in your collection?
The populate argument could just simply get iterated over and set whatever property matches the current key for that iteration…
Or are you wanting to be able to pass in N about of arguments for whatever reason?
March 8th, 2010 at 5:14 pm
Yeah, the downside to a populate argument is that for people not running CF 8 they would have to create a collection first, so that means doing structNew(), assigning a bunch of keys, etc., which would get verbose and kind of defeat the purpose.
March 29th, 2010 at 8:35 pm
Kind of a side issue, but for building a struct concisely pre the native language construct, many folks use something like this:
I’m not such a fan of ordered args, at least more than about two. Named args are self-documenting, worth the typing IMO.
On your main idea, I’m not sure I see a big advantage to having a method in the bean factory to set a bunch of dynamic properties at once, vs having it in the objects themselves. A generic populateFields method in a base class feels more appropriate than moving it out to the bean factory. DI seems more about app structure and object relationships, where injecting dynamic values like more of an object-specific convenience.
OTOH, it doesn’t hurt to have it if it can be done cleanly, so if it floats other folks’ boat, I say go for it.
My $.000002…
March 29th, 2010 at 8:36 pm
Eh, code bits didn’t come through. Just a method to return arguments — pass in name args, get out a struct with the passed values in the passed fields.
d
March 29th, 2010 at 8:47 pm
@Dave, thanks for the feedback. Doesn’t seem like a ton of people are using Lightwire in the first place based on the amount of feedback. Even the AOP stuff I did got pretty much zero response, and it’s a lot more significant than this. This was just a nice to have. So without more interest, it won’t make it into the main codebase, which isn’t really a big deal. Like you said, having a configure() or populate() method isn’t that huge of a deal, especially since there would probably be limited cases.