If we are using Coldbox, can we use Wirebox separately? I know it sounds strange, but we want to be able to use Wirebox in some apps that will not use Coldbox. But we also want to use Wirebox for some things before Coldbox will be instantiated, specifically environment detection that requires objects from our ServiceLayer, determining our “portal” flavor for telling Coldbox to use different configs for Coldbox and Logbox and maybe Cachebox.
Our primary app does use Coldbox and my concern is that Coldbox has (a version of) Wirebox built in. If we setup Wirebox independently before Coldbox, will Coldbox say “I need to create Wirebox, oh wait! Wirebox is already running, yay! I’ll just use that one!”
Will this work? Or does the standalone Wirebox have known incompatibilities with Coldbox, if it were to use it, if it’s smart enough to do that?
Yes, but one of my other concerns is about version conflicts between built-in vs. stand-alone Wirebox as far as Coldbox is concerned. Also, I believe that the location of the storage is different. Would love to have Luis chime in here as to his opinion.
There should be no issues, even though Wirebox is distributed and used within Coldbox Applications I strongly believe that the framework is usable on its own.
The examples on how to use it on its own, just change the paths to match that off the Coldbox installed version and you should have no problems.
Internally, ColdBox will load up an instance of an Injector to be able to create plugins, handlers, etc. So an injector will ALWAYS be created internally and stored as application.wirebox, unless you change the storage scope in your main application’s config. http://wiki.coldbox.org/wiki/WireBox.cfm#scopeRegistration
You can always create as many injectors as you like manually. So you creating an injector manually at startup is perfectly fine, just make sure that its scope storage it is NOT the same as the main application. Second, since you are creating one manually, I would probably also set it as a parent injector to my main application.
So let’s say your code looks like this in your applicationStart()
new coldbox.system.ioc.Injector( binder=“standlone.binder” );
and the scope storage for this in the binder is “application.wirebox_standalone”;
Then in your main application’s binder, you can set your parent injector:
To add a bit to what Luis said, WireBox is absolutely usable as a standalone library and has been since ColdBox 3.0. The WireBox inside of ColdBox isn’t a “version’ of WireBox, it’s the exact same thing. In fact, we only have one code repo for WireBox and that’s the standard ColdBox repo on GitHub. When Luis builds the WireBox standalone he has an ant script that basically takes the coldbox.system.ioc folder and renames it to wirebox.system.ioc and then does a find and replace on “coldbox.system” to 'wirebox.system”. Other than that, it’s the exact same code. You can also create as many injectors as you like in an application as Luis said below. Just remember WireBox standalone has a default scope registration of application.wirebox.
Our WireBox ref card shows how to create stand-alone instance of Wirebox:
Definitely was able to reproduce the “overwriting” scenario as Luis described. While considering the “parent injector” option, and after scanning everything I could find online, I don’t think I understand the purpose of a parent injector? What’s it for? Why would one want to do this? What makes the concept special?
Basically if an injector can’t find a mapping and it has a parent injector, it wilask the parent injector for it. If you needed whatever service it is that does your environment detection available BOTH outside of ColdBox and inside of ColdBox, but didn’t want to have two versions of it floating around, one in each injector-- you could only define it in the stand along injector and then make the standalone injector a parent of ColdBox’s injector. That way your mapping is only declared once, and still available inside ColdBox as it will simply refer to the parent injector to provide the CFC.
I think I very much like this idea (and your explanation).
So, is this the right procedure?
• Instantiate the standalone Wirebox, with the config file for those objects I need now. (Like application.wireboxPreColdbox, with config/wireboxPre.cfc)
• Instantiate Coldbox (and built-in Wirebox)
• After that’s complete (in onAppStart), do application.wirebox.parentInjector = application.wireboxPreColdbox
Sure, but if different applications had different setups (and it would be the app.cfc instantiating the stand-alone), I would prefer to do it at the app-level. However, you make a good point. If I had some eagerInit()'s that started looking for stuff in the parent, it wouldn’t be there yet. I guess we could stick to a naming convention, like application.wireboxStandalone, and in the coldbox.wirebox config, use <cfif structKeyExists(application, ‘wireboxStandalone’)>[set parent injector]
