In a stand alone installation of wirebox + cachebox, is there anything really really wrong with actually creating two named instances of wirebox?
Mike Craig
You can have as many injectors as you want. Just edit their respective WireBox.cfc config and change the scope registration key. That being said, I’ve never come across many good reasons to need two injectors. Can you explain the limitations you’re running into with a single Wirebox injector instance?
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
I thought you’d never ask 
Here it goes.
Huge SaaS application…“legacy”…moving everyone to a coldbox way of thinking very slowly. Every CFC relies on a public “account” and a data “schema” variable in order to work…this means for any application context, all the cfcs only work for ONE account/schema…but now, we want to be able to create a web application, installed in the same SaaS code base, they can cross accounts. I cannot use the same code, currently, to do that because it all relies on those public variables, which are immutable.
If I create all these cfc’s to use injected objects and create to wirebox instances, one instance can be for the application context, one can be used for the utility tools that cross accounts. Of course, I can change all the legacy code to receive an object that contains the schema and account it and I would not need two injectors, but that’s a whole lot of code changing that we would not have time for in this release cycle. So I need to “shortcut” that process and so far, this is the best I could come up with.
Ahh, dealing with Legacy fun I can’t say I followed all of that, but if multiple injectors are working and make you’re life easier then I say it’s a win!
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
Ok, this is still bothering me. Let’s think of it this way instead:
I have a single class that I’d normally map via wirebox as a singleton, it is an Account object (well call it that). Just about every other class needs the information in Account so I’d naturally just inject it into any other object that needs it. This basically creates a one to many relationship between a single account and many objects.
Now, the client wants to leverage all that logic but with a different account. Imagine a special user who can log into a SaaS application as one client but has special permissions to compare that account data with another account data. In order to accomplish this, all those many objects need a different account injected into them…but since I injected a singleton account object, the only way I could override all those classes that consume an Account object is to manually override the property on the fly…but then, it would need to be set back and probably locked and who knows what kinds of collisions would happen because most of those other objects are also all singletons, as they likely should be.
So my thinking was that I’d create another wirebox instance and poof, I should be able to create another set of those classes…no? Since any model created is created from a single injector instances, that seems to make sense. So long as injector #2 maps the same named objects, the should always be populated exclusive of the instanced created for injector #1.
The explanation may end up helping me more than anyone reading it
I’m unclear on whether account is a singleton or a transient. It sounds like you only create it once, but how many account objects can your application have? typically if you have an object for which an instance may exist for every record in a certain database table, that’s a transient. Now that being said, you can still persist a transient in a scope, a cache, or another object (like session.user)
First option: Implement some sort of “switch user” functionality where an admin can actually switch on the fly to another user in the system and impersonate them to view their data
Second option (recommended): Stop injecting Account directly. Instead, inject a helper or service object that retrieves the necessary account at runtime. That would allow you to override the account being dealt with at run time based on whatever it is in your application that decides what account you’re using. Of course, in this scenario you’d only place the account object in local scopes so there’s no bleed over to other threads.
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
In this case Account is a singleton and represents the SaaS application account. However, your second option note is exactly the direction I need to be thinking in…excellent idea, as always Brad.
Mike