Have a client willing to at least now go as far as Wirebox…a major leap for him and a great thing for everyone. However, this CF app has some home-spun plugin architecture so while at the “top of the app”, we can have one instance of an injector and a binder to create all the high level mappings, IF, and I do mean IF, an “account” uses plugin “X”, that plugin has it’s own model that needs to be mapped in…but I won’t know IF and inevitable, don’t care when…I just know it will and it will AFTER the initial injector is loaded.
I would like to be able use a binder cfc in the various plugins that contain their own, pretty much stand alone, object model so that we have access to all the grace, beauty and flexibility a binder has to offer, but want to “inject” (pardon the choice of words) THAT binder, binder 2 INTO the one and only instance of the injector already created for the whole of the application.
Is this possible, is there a better way?
I don’t want to miss this opportunity and I don’t want to have to re-engineer anything in the plugins other than mapping them for DI.
Not sure I completely followed all that, but an injector only has one binder. Here are some thoughts though:
If there is zero overlap in the models being used, just create multiple injectors. Make sure you update scope registration so they don’t conflict. Heck, every plugin could have it’s own injector I suppose if they were islands unto themselves
If you’re just wanting to separate config, you can break up the mappings and include them as .cfm files into the WireBox config.
If you don’t know the configuration right away, can you simply wait to configure WireBox until you do know it? It can be created any time you want as long as you create it before trying to use it the first time
Injectors can also have parent injectors. That way ‘shared’ objects could be mapped in the parent, and models specific to one plugin could be mapped in a child injector. If you ask an injector for a mapping and it can’t find it, the parent will be asked.
If you have different applications per client, you can create multiple binders and load the appropriate one into the application based on client.
Mappings can be added programmatically at any time after WireBox is loaded. Just do wirebox.getBinder.map().to() etc. Even scan locations can be added after the fact. All of our libraries have programmatic APIs so you could even configure it based on external configuration ilke a database table or something.
Let me know if those suggestions get you going at all.
Thanks Brad…gratefully…I thought of all of these EXCEPT this one…and it might just be the magic:
Injectors can also have parent injectors. That way ‘shared’ objects could be mapped in the parent, and models specific to one plugin could be mapped in a child injector. If you ask an injector for a mapping and it can’t find it, the parent will be asked.
I think we can work with that. One of the easier options you point out is to first figure out what you need, then load the whole thing…but initially we stopped dead on that because the new “pluginservice” i’d write to “register” the home-grown plugins should be wireboxed in the first place…which means my primary “parent” binder is already in place BEFORE I know what is going to be added.
Using the API features to map contents is the next most likely candidate and the strongest so far because at least the pluginservice could tap into a cfm template that just does all the mapping via the api functions.
The parent child solutions offer the one thing I think I really wanted to keep, and that was the binder.cfc.
I’m not sure which way we’ll go, but you’ve confirmed the things I already thought might be good options and given me something new I did not know that could prove even more useful.
