[wirebox-1.7] Consuming wirebox properties after injector is configured -- is there a better way?

So, I discovered there is a cool way to add properties to my injector so I added a couple properties to the injector thinking that I’d be able to inject those properties sooooo easily into other injected classes…and it does work…wonderfully in fact.

So I thought, ok, using wirebox map() instructions, I should be able to tell every class I need to create whether or not I want those properties injected. While I have used that technique before, it seemed that the one thing I could not do was rely on wirebox properties as injected properties to other mapping because the wirebox injector was still being configured…at least that is how it seemed…and it sort of made sense…so I scratched that idea.

But, I still not only wanted to do this once (just in case minds changed, etc) but also wanted to just forget about for any object instanced created through the injector…so I could always rely on it being there.

So, I stepped back to a different habit and created a class where I could do this once and then extend it from every other class. This of course, worked, and nicely…but now I’m converting some old legacy code and the work really must now begin. What I’m finding is that if I were able to inject these properties through the mapping process, I might have a lot less work on my hands…at least as an interim solution until I have to to actually rewrite some very old code.

MOST (not all need injector and populator) every class needs the following (the last three being the important ones)

property name=“injector” inject=“wirebox”;
property name=“populator” inject=“wirebox:populator”;
property name=“ds” inject=“wirebox:property:ds” scope=“this”;
property name=“schema” inject=“wirebox:property:schema” scope=“this”;
property name=“dbms” inject=“wirebox:property:dbms” scope=“this”;

So…is there a better approach to this problem? Did I misunderstand some rogue error when trying to inject wirebox properties in the map() process? Does this sound reasonable? I mean, the class extend works, but this seems more “global” than extending.

Thoughts, suggestions, questions?


In situations like that, you could also look at it from another angle. For example this example indicates you could use a bean with methods to retrieve what you want.

For example you could almost reduce what your doing to injecting it into the bean or however it is being setup, then inject the bean and call a get method to return a struct of settings an array of settings or if you prefer throw an accessor onto the bean and use the getter for property individually.

Hi Mike.

I haven’t used Wirebox in quite some time now, but looking through the docs (specifically this concise list of DI methods: http://wiki.coldbox.org/wiki/WireBox.cfm#Dependencies_DSL ) it looks to me like there might be two or three of those that would address your need as I understand it to be! Specifically, some combination of the property() and virtualInheritance() methods caught my eye. I’m thinking you could define these properties, alias it with a mapping, then tell Wirebox to mixin those mapped properties via a chained virtualInheritance() method in your binder configuration.

just tossing it out there! :slight_smile:


Thanks Andrew…that seems a really good idea…new angles is what I was hoping to get…I’ll look at that as it might be helpful. Doug, thanks too…I weed through so much documentation it’s easy for me to overlook things.